Wire-protocol enhancements (was: Re: [PATCH 1 of 1] sshserver: add varargs capability)

Sune Foldager cryo at cyanite.org
Fri Feb 12 04:14:01 CST 2010


Let's look at this in a slightly different way. Here are some
observations and suggestions.

- We don't really need client capabilities in general; we just need
optional/variable arguments for all commands, so we can enhance as we
see fit. We have this for http, so we just need to fix ssh in this respect.

- ssh: We do need to communicate both server-to-client and
client-to-server, that we're using the new argument-flexible format. In
my first patch I used a capability 'varargs', and in my suggestion
earlier I used 'protocol=2'. If we think we'll never need to change the
underlying protocol again, we can avoid mentioning 'versions' and stuff
like that and use something similar to 'varargs' or maybe
'ssh-protocol-final' ;-). Similarly, we can remove the protocol version
that I proposed the client send to the server (this will make it harder
to make subsequent protocol changes in a backwards-compatible way, though).

- http: We could technically do with optional arguments (indicating "I
want chunked respose for this command's binary data") and a capability
here, but it would introduce a discrepancy between the two protocols,
and we're trying to bring them closer together, after all. The other
solution, then is a header which I think I proposed we could call
X-Protocol, keeping the protocol-version way of thinking about this.
Again, we can call it something else to avoid bringing versions into
this... but we do need it somehow :-).

- ssh and http are highly independent wrt. the above, so, since ssh is
by the simplest, we can start out with that as soon as we decide on the
open issues above... and on JSON (although switching to that calls for
bigger changes to http, i.e. switching to putting the argument package
in POST data).

So I don't really know... I realize we generally don't roll out entire
new protocol versions and such, but these changes are pretty fundamental
at the low-level protocol level. The higher protocol level, on the other
hand, is pretty much unaffected.

/Sune


More information about the Mercurial-devel mailing list