[RFC] Add a Transport.human_url method?

[Michael Hudson]

Andrew Bennetts 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?

I'm not sure I see the point.  When would human_url() and external_url()
be different?

Cheers,
mwh