[RFC] lp: URLs as a directory service?

[John Arbash Meinel]

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

Aaron Bentley wrote:
| 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

One of the reasons to delay resolution of lp:foo is because of filenames.

So that doing "bzr branch lp:project" creates a directory named "project" rather
than redirecting to http://bazaar.launchpad.net/~project/project/trunk and
creating a directory named 'trunk'.

I'm not terribly concerned about having get_transport() do a lookup, as long as
it only does it when things match. (So if you do bzr branch /local/path it
shouldn't connect to lp to see if that was an lp url.)
We do have a general policy that getting a transport doesn't connect until you
start actually using it. Though I don't really have an idea of when we would
grab a Transport but not actually do something with it.


I'm not sure what URL manipulations you are thinking of. So maybe more of an
understanding about what you find lacking in our current system would be good.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHvGO/JdeBCYSNAAMRAqTtAJwMCbA1ty+Tgn/D5oWy64sCen5dBwCePCv6
DN2unq6+qr8htX9f6MmZo3U=
=6fSw
-----END PGP SIGNATURE-----