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

[Augie Fackler]

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

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

>
> 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
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel