Default performance of 'lp:foo' URLs

[Martin Pool]

2009/12/2 INADA Naoki <songofacandy at gmail.com>:
> On Wed, Dec 2, 2009 at 1:37 PM, Martin Pool <mbp at canonical.com> wrote:
>> Can we please stop bikeshedding and start on a patch for this?  Any of
>> bzr+http, anonymous ssh, or bzr over tcp would be an improvement.  All
>> the code needed to implement this is out there and various people will
>> happily mentor.

What I perhaps should have said, was: we know that there will be a lot
of performance variability, but all of them will run at comparable
rates in practice.  Reducing that overhead is useful, but measuring
random numbers it does not seem very useful in choosing which one
Launchpad should deploy.

What is most interesting to me is which one is most feasible to deploy
and which will eventually give the best user experience.

For the channels themselves:

ssh:
 + unlikely to be corrupted by firewalls
 - may not get through firewalls at all
 + channel-level compression
 + channel-level integrity checks
 + consistent with what we do for non-anonymous access
 - more cpu overhead for client and server
 - may have complicated interactions with the user's environment:
openssh, pageant, etc
 + probably can be done entirely in "userspace" in the Launchpad
application code, without running new services or opening new ports
 - more handshaking to start up
 + can hold connections open

http:
 + probably goes through firewalls
 - may be messed up by bad proxies, but less so than plain http

tcp:
 + smallest possible amount of handshaking
 + smallest amount of cpu overhead

We could eventually offer more than one of course.

So we could take a small step of just running any of these things, but
we should possibly also look at the broader picture of lp: and
lp-login.  There are some inefficiencies and bugs there that we could
address too.

They include:

All access to lp: does an xmlrpc to the server; it would be nice to
avoid that as both a delay and a source of problems.  Instead it would
be good to just send a request and let the server redirect if
necessary.

It would be better if pushing to a branch didn't give you an error,
but rather asked you to authenticate, either interactively or by
re-running the command.

It would be nice for robustness, I think, if lp-login just meant "set
my username" (and maybe verify it works) and no more, and you could
easily see how to get back to the unauthenticated behaviour, either
permanently or for one command.

So for that reason I think it would be suboptimal if telling bzr your
lp username made it switch from http to ssh and therefore introduced
new networking problems.  They should be independent layers.

There are some more bugs here.  Changing from http could possibly fix
them in one fell swoop.

> -1 for bzr+anonymous ssh. Many read only users doesn't know about ssh well.
> +0.5 for bzr+http. I want to branch fast with http proxy.

Whatever we do, the user shouldn't normally know about it because it
will be automatically invoked by lp:foo.  Of course if it doesn't
work, they may need to know about it.

-- 
Martin <http://launchpad.net/~mbp/>