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

[John Arbash Meinel]

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

6) Have large requests use a streaming protocol (chunked transfer encoding) so
they can fail early rather than after streaming all 10 MB across the wire.
Obviously this requires getting chunked/streaming working.

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

I agree with 2. And I think Robert has a reasonable idea about why not 4. I
think we can keep (4) in our minds, and if there is strong user need for it, we
can implement it then.

John
=:->

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

iD8DBQFHFkfvJdeBCYSNAAMRAoyvAJ4wvNLoFtp+xsbzcQYSNLLEvcHXwgCgmUP+
y/WbfPLbb4i8YvmW0vd417A=
=EGS0
-----END PGP SIGNATURE-----