[PATCH 1 of 1] sshserver: add varargs capability

Sune Foldager cryo at cyanite.org
Wed Feb 10 13:08:13 CST 2010


Augie Fackler wrote:
> On Wed, Feb 10, 2010 at 8:45 AM, Sune Foldager <cryo at cyanite.org> wrote:
>> We're going to need server capabilities to make any changes in the wire
>> protocol both for ssh (adding flexible arguments) and http (adding oob
>> error stream).
> 
> Having just implemented chunked transfer encoding, I'm confident we
> can't tuck extra information into the chunk headers at the http level.
> When we read from the http response object, we're totally oblivious of
> the presence of chunked transfers.

Yes :-(... well it doesn't matter; we'll just dont use chunked transfer
(as far as httplib goes), but do it anyway.. our own chunked transfer
(which can be whatever we want, even identical to http's). This also
occured to me earlier, as I was looking at httplib code.

>> My initial patch dealt with ssh in a simple way (no JSON
>> or similar) and called the capability 'varargs'. We may want to go with
>> a different name instead, such as a protocol version number; maybe
>> "v1.1" or whatever system we can come up with.
>>
>> I realize http already transmits something like that back, although I am
>> not sure it's actually meant to be a version number.
> 
> I'm pretty sure that's a protocol version, so we can use that.

Yeah, although
1) it doesn't seem we send protocol version in do_cmd; we receive it
from the server.
2) a different method is needed for ssh, where we don't have headers. A
method similar to the one in my patch, say.

>> Due to the
>> stateless nature, we need to send it with all commands, OR the server
>> needs to be able to figure out the version from the command sent. This
>> is the case for my ssh patch; the server can see the difference.
> 
> http already does this in a header, see do_cmd in httprepo

In the response from the server only, where we already have
capabilities. But we can add them as arguments; no need to keep separate
concepts (arguments and headers) IMO :)

/Sune



More information about the Mercurial-devel mailing list