On Wed, Aug 26, 2009 at 7:44 AM,
<address@hidden> wrote:
But if protocol negotiation won't do the whole job (and it looks as
if it may not) it would simplify my life immensely if the protocol to
use were made a command-line parameter on the mtn sync command. We
could even store a default value of this parameter in the _MTN directory
after a successful sync.
It seems like it should be possible for a *new* client to "negotiate" a protocol to use with an old server. When the new client connects to the old server, the older server sends the initial hello that says "I want netsync protocol version 6" (which is what it is currently at) so the new client just needs to respect this and use the old protocol. Even if the client needs to do do something drastic and reconnect, it should be able to come up with some means of talking to the old server. I'm assuming here that the server always sends the initial hello packet,
which I think someone mentioned earlier in one of these threads.
Individual client upgrades are presumably easier than server
upgrades and this would allow for clients to be upgraded ahead of
servers so that all clients can be ready for a pending server upgrade.
Such a command-line parameter would cut down on the number of
versions of monotone that have to be maintained, and would simplify
getting it all through distro maintainers. End users would have to be
informed of the issues, though.
> It would be nice if the 0.45 server could deal gracefully with older
> clients, and vice-versa, but it's not a requirement.
And there seems to be some question whether it's reliably possible to
recognise older clients with the protocol they understand at present.
At a glance, I concur with Tim that there's no space in the initial
packet (other than the nonce) for a new server to hint to a client that
it speaks a newer protocol.
It _is_ a requirement that the 0.45 server and client be able to deal
> gracefully with any future client or server, even in the case of
> another netsync protocol change.
And that we cen design in now.
One discussion that we've had before centers around protocol version numbers verses specific features. Iirc SMTP's EHLO command may respond with a list of keywords indicating the various optional features that a particular implementation supports.
Personally, I think I prefer this scheme over a simple version number check. It makes feature support explicit rather than implicit and up to the respective parties to infer based on what protocol versions they find.