[RFC] Add a Transport.human_url method?
jml at mumak.net
Fri Jul 31 09:19:39 BST 2009
On Fri, Jul 24, 2009 at 2:39 PM, Andrew
Bennetts<andrew.bennetts at canonical.com> wrote:
> This idea sprang from my patch about LockContention errors that I'm about to
> Currently there are two ways to get a URL from a Transport: t.base and
> t.external_url(). I don't think these two methods quite cover all our use
> 1. base: is for in-process use. You can do get_transport(t.base) and get a
> transport object equivalent t. t.base might not be meaningful outside of
> this process (e.g. for memory or chroot transports, or decorated
> 2. external_url(): is for sharing with other processes. Another process on this
> host can probably use this URL to access the same resource (modulo
> authentication etc). If there is no such URL then it raises an exception.
> I think there may be value in having a third method:
> 3. human_url(): is for reporting to humans in errors and the like. This is
> t.external_url() if it exists, but otherwise t.base, which is still better
> than nothing. The attached patch to implement this basically moves a
> private helper that my LockContention patch added to a public method of
> Thinking about this, perhaps the LockContention serialisation in my patch is
> still not quite ideal... ideally we'd be sending relpaths over the wire rather
> than URLs. Hmm. Although I can imagine cases where the server might legitimately
> want to send an error about a LockContention on a lock not on that host, but
> perhaps that's too marginal.
> What do other people think?
This sounds like a good idea. Without actually paging the code in, I
can imagine this would be useful for lp.codehosting.
More information about the bazaar