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

John Arbash Meinel john at arbash-meinel.com
Thu Oct 18 03:53:43 BST 2007


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

Andrew Bennetts wrote:
> 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.)
> 

Then why is there an OPTIONS http request? (Or is that a WebDAV request?)

> 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.


I can't say that the arguments you give (for upgrading/downgrading while a
transaction is in process) really mean anything to me. I think it might be an
interesting mental idea. But in actuality I would never expect an upgrade in
place to survive the current connection. (Like closing your laptop for a week...)

Anyway, I understand the goal of being stateless. I'm not sure that we really
want to get into the habit of supporting 10 versions of the 'GET' protocol
because we happened to try it a different way at one point. Which means that
you can't really support all clients against all servers.
So I think it is good to try to be stateless. I just don't think you're going
to get out of it as much as you might think you would.

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

iD8DBQFHFsq2JdeBCYSNAAMRAmvnAKDJp7vn+wdZSUMGYsvv/OVadP7/EwCcD/u1
MWvBFd+kiBEDhdO0nMHs+wk=
=C1BA
-----END PGP SIGNATURE-----



More information about the bazaar mailing list