[PATCH 1 of 1] sshserver: add varargs capability

[Dirkjan Ochtman]

On Wed, Feb 10, 2010 at 23:55, Sune Foldager <cryo at cyanite.org> wrote:
> Ok, here's a proposal; I'll start to implement parts of it soon, I
> think, and we can discuss the details :).

I think it'd be useful to distinguish between commands with binary
payloads (that is, bundles) and the other commands (discovery). In
particular, I think we probably don't want to do chunked transfer for
the latter, because it isn't worth the complexity and it doesn't
particularly help (you have all the information before you start
sending the response).

> 1. Protocol versions
> We'll call the current protocols used version 1, and the new ones
> version 2. Versions will in general be positive integers; we need not
> keep the different wire protocol versions identical, but this time
> around we'll advance both.

Where does this fit in with our capabilities structure? We generally
want to do semantic versioning, not just wholesale revisions. Even if
it doesn't work that way here, we should detail in a spec (something
like your email) why that might be.

> 2. Common features
> - Capabilities: protocol=1,2 or similar, from server to client as usual.
> - Request: client can communicate protocol version used.
> - Request: command name + variable arguments OR
>           command name + JSON (let's discuss which one).
> - Response: separate output and error stream.
>
> 3. SSH
> Initial line will be:
> <protocol version> <command name> [possible version dependent data]
>
> For version 2:
> 2 <command name> <argument count>  OR
> 2 <command name> <argument length> (in case of JSON)
> <arguments as before, or JSON as a single chunk>
>
> We can thus easily tell the current version from the new one.
>
> 4. HTTP
> Protocol version will be put in X-Protocol: <version number> header.

Request, response, or both? What will do for the first request? We
have opposing goals here: on the one hand, we want to minimize round
trips for HTTP, on the other hand we'd like to find out server caps
before we start exchanging data.

> Response stream will be segmented using an approach similar to chunked
> transfer encoding: Each chunk/segment will start with a line containing
> the size of the segment and its type (output or error), for instance:
> <size in decimal, hex or whatever> <type>
> followed by data. A 0-chunk terminates the stream, if we think it necessary.
>
> In case of a server error, we pad the current (output) chunk, and send
> an error chunk afterwards. The client MUST check for trailing error
> chunks, as their presense can mean that the previous output chunk is
> invalid.

This approach sounds good, though I don't think we should complicate
the non-bundle commands this way.

Are you trying to put this in 1.5?

Cheers,

Dirkjan