[RFC] Add a Transport.human_url method?

[Jonathan Lange]

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
> merge.[1]
>
> 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
> cases.
>
> 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
>    transports).
>
> 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
>    transport.
>
> 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.

jml