[RFC] Add a Transport.human_url method?
andrew.bennetts at canonical.com
Fri Jul 24 05:39:46 BST 2009
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4287 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090724/8dba7aef/attachment.bin
More information about the bazaar