Wire-protocol enhancements

Sune Foldager cryo at cyanite.org
Fri Feb 12 10:04:00 CST 2010


On 12-02-2010 15:23, Augie Fackler wrote:
> On Feb 12, 2010, at 4:14 AM, Sune Foldager wrote:

>> - 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).
> 
> I'm not sure I understand what you need varargs for? Can you explain a
> bit more for someone that's never looked at the ssh protocol?

There is some more information in the rest of the thread. Basically, in
the ssh wire protocol each command has a fixed number of arguments; this
number is not communicated from the client to the server, and so is hard
coded. Http is much more flexible, and I want to add that flexibility to
ssh as well (so we can use extra arguments to enable features like 'send
me lwcopy diffs' etc.)

>> - 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 :-).
> 
> Or add an hg-varargs: header?

Yes, a header is what I was planning on, although not varargs since http
has that already (and ssh needs it). For http it's to enable a mode
where binary data sent from the server is segmented into output and
error. So hg-segmented-something or whatever :)

>> - 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).
> 
> My immediate thought is that it'd be nice if we could avoid that, as
> right now it's really trivial to make a requires-auth-for-only-push http
> server (just require auth for POST, and you're done).

Good point, actually... although we may need to change it sometime
anyway since there are some problems with very long query_strings for
some web servers.

/Sune


More information about the Mercurial-devel mailing list