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

Andrew Bennetts andrew at canonical.com
Wed Oct 17 07:13:08 BST 2007


As the smart server protocol changes, we need to make sure that different
versions of the client and server can interoperate.  In many cases this easy: if
new versions of the server supports older request methods, then older clients
will continue to work.  Similarly, new versions of the client can often support
older servers at minimal cost, by simply trying a request, and if the server
doesn't recognise it, downgrade to something else.  The cost is one wasted
roundtrip, a bit of fairly simple fallback logic in the client, and keeping the
old request logic in the client and server.

If the request is large (e.g. pushing 10MB container of revision data), then
this isn't so good.  Sending a 10MB request just to get back a “sorry, I don't
understand” response is going to be pretty slow.  What should we do about this?

The specific case is I'm thinking of is that I want to implement a smart method
to add a set of revisions to a repository (like the recently added method to
retrieve a set of revisions).  Some options:

  1) always try the large request, and then fallback.
  2) always try the large request, and then fallback, but also warn the user
     that they should upgrade the server to get much better performance.
  3) send a “do you support request X?” request first (possibly integrate this
     into the existing “hello” request).
  4) add a configuration option to locations.conf so that users can turn off
     this feature for known-old servers.
  5) add a configuration option to the client to enable it (and have the feature
     by off by default).

I'm thinking I'll probably do 2 and perhaps also 4 (default to trying the large
request, warn the user if the server is too old to support fast pushes, and
allow the user to configure their client to avoid using this method if they
know a server is too old).  The warnings from 2 might be a little annoying if
you don't control the server-side, but in combination with 4 you'd be able to
turn them off.  And people should be encouraged to upgrade to faster, better
versions of bzr :)

I don't much like 3, as I'd rather keep the protocol stateless, and it means
unavoidable roundtrips for no actual work.  I don't like 5, because I'd like new
clients and servers to be fast by default.  Hence my current preference for 2
(plus 4).

Does anyone have any comments, or other suggestions?

-Andrew.




More information about the bazaar mailing list