What to do about HPSS protocol backwards compatibility for faster push?

[Andrew Bennetts]

Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Andrew Bennetts wrote:
> > As the smart server protocol changes, we need to make sure that different
> > versions of the client and server can interoperate.
> 
> What about just advertising capabilities in the initial handshake?
> 
> This could either be inferred from the version, or be explicit like smtp.

That's a variant of option 3:

> >   3) send a “do you support request X?” request first (possibly integrate this
> >      into the existing “hello” request).

And so it suffers from both problems I listed with that option, which are
statefulness and an excess roundtrip (although only one excess roundtrip per
conversation, and one we already make, but I'd like to get rid of that).

The main reason I'd like to have no state between requests is that it makes
correctly transporting the smart protocol over HTTP simple, because HTTP
inherently has the same assumption that each request is entirely self-contained.
(modulo bits of the RFC like e.g. clients SHOULD NOT expect a 100 Continue from
an origin server that it's never seen one from... i.e. degrading gracefully in
the presence of older peers.)

Ideally I'd like to insulate the smart protocol from the problems that
statefulness allows.  For example, an HTTP server configured so that it happens
to pass requests for /foo/bar to one backend server and /foo/qux to another,
that happen to be running different versions of Bazaar.  Or pool of servers
(whether http://, bzr:// or bzr+ssh://) that are load-balancing requests, and
being upgraded to a new version of Bazaar.  Or if I suspend my laptop half-way
through a remote bzr operation, and resume it a week later from a different
network.  Or if I have a long-running client and don't want to have to
periodically re-handshake just in case the server software has changed.

Those are all edge cases, but they help explain why I do find the design of
using stateless requests quite attractive.  If there's no problems in hitting
different versions of the code in subsequent requests (so long as all versions
have a common subset that the client can fallback to if necessary), then it
makes load balancing and upgrading (or downgrading!) a bzr server conceptually
quite simple.  I'm hoping this will help make adminstration of a smart server
pretty painless.  My gut feeling is enforcing this sort of simplicity will help
reliability.

So, I'm not absolutely against advertising capabilities.  Perhaps it will become
too convenient to avoid if we want to support some radical new feature without
troubling older clients, or just if the protocol stays in considerable flux for
a long time (I hope it doesn't though!).  But my inclination is to avoid it if
we can; it just doesn't feel “right” to me.  I'm increasingly satisfied that we
can cope ok with this immediate problem (faster push) without doing it... I'm
hoping we can continue like that.  We'll see if I'm right or not :)

(Btw, I'm not against transmitting version information.  I do think every
request and response ought to include some software version information, but
just for debugging and logging purposes.)

-Andrew.