[RFC] lp: URLs as a directory service?

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

I'd like to change the way Launchpad URLs are handled by Bazaar.  I
think it would make a lot more sense to define a new layer that would
provide a directory service.  So get_transport('lp:bzr') would perform a
lookup and return a transport for
"http://bazaar.launchpad.net/~bzr/bzr/trunk/".

This would allow URL manipulations to work properly on transports
acquired from launchpad URLs, which would mean fewer bugs in this area
and less special-casing.  (We would just need to be sure to always
perform URL manipulations on the transport, not the URL used to acquire it.)

I talked with James Henstridge about this, and he said that the reason
they did not implement it this way originally was because they had been
told not to.  Specifically, they were told that get_transport must not
perform network operations.  The rationale was that the bzr codebase
assumed get_transport was cheap, but this would make it expensive.

I don't think we currently behave as though get_transport is cheap.  We
try to reuse transports as much as we can.  But more importantly, an
"lp:" transport is not useful until it has been looked up.  I think that
it is very uncommon for lp:transports to not be looked up at one point
or another, so delaying the lookup after get_transport is just delaying
the inevitable.

Thoughts?

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHvFoe0F+nu1YWqI0RAgIIAJ43rqhTKMgxXgNGJbM6tEw/G2tOowCgibWz
8322Pw5KdIcaiet9yvehN9A=
=8gmB
-----END PGP SIGNATURE-----