Wire-protocol enhancements (was: Re: [PATCH 1 of 1] sshserver: add varargs capability)
durin42 at gmail.com
Fri Feb 12 08:23:44 CST 2010
On Feb 12, 2010, at 4:14 AM, Sune Foldager wrote:
> 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
> - ssh: We do need to communicate both server-to-client and
> client-to-server, that we're using the new argument-flexible format.
> 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
> underlying protocol again, we can avoid mentioning 'versions' and
> like that and use something similar to 'varargs' or maybe
> 'ssh-protocol-final' ;-). Similarly, we can remove the protocol
> that I proposed the client send to the server (this will make it
> to make subsequent protocol changes in a backwards-compatible way,
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?
> - 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?
> - 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
> 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).
> 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
> at the low-level protocol level. The higher protocol level, on the
> hand, is pretty much unaffected.
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
More information about the Mercurial-devel