Differences between revisions 3 and 4
Revision 3 as of 2010-02-09 15:42:22
Size: 2712
Editor: cyanite
Revision 4 as of 2010-02-09 15:50:44
Size: 2784
Editor: tonfa
Comment: ssh advantages
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
 1. The ssh protocol is less flexible to extension than the http protocol.  1. The ssh protocol is less flexible to extension than the http protocol. But ssh can provide out-of-band messages (via stderr) and return codes.

Overview and motivation

This page discusses the low-level parts of the two wire protocols: ssh and http. The high-level parts (command set, arguments etc.) are not the scope of the unification.

Currently, handling the two wire protocols is almost entirely separate in the code; each has an adaption layer consisting of a function for each available command, which interacts with the common backend in the appropriate way. The two adaption layers are vaguely similar, but far from identical. Also, the feature set is different in the two underlying protocols. In particular, the ssh protocol is less flexible when it comes to argument handling. To sum up some observations about the current situation (not all of these are necessarily issues we should address):

  1. The ssh protocol is less flexible to extension than the http protocol. But ssh can provide out-of-band messages (via stderr) and return codes.
  2. The transfer formats are dissimilar.
  3. The two adaption layers carry out a lot of the same work, but have little shared code.

In particular, the first point above means that we can't easily add optional arguments to the ssh protocol to enable feature extensions (such as light-weight copies), client capabilities and similar, whereas this is not a problem for http.

What we should do about it

We could proceed in a few phases as follows:

  1. Discuss a common feature set we want (and need) the low-level protocols to support, in order to ensure future flexibility and easy backwards compatibility.
  2. Discuss how this information should be transfered, and if we can somehow at this point (without breakage) make the two transfer formats more similar.
  3. Change the protocols so the common feature set is properly supported.
  4. Consider how the common feature set can be unified in the code, write the common layer for this and change the current adaptors to use it.

Feature set

Current common feature set

Commands are sent from the client (stateful) to the server (stateless), and consist of a command name and a number of arguments in a key-value format. The number of arguments for each command is fixed due to limitations in the ssh protocol.


The easiest is to define the feature set as: We need to be able to send commands (text string) with a dynamic number of named arguments containing primarily text, but potentially arbitrary, data. The number and names of the arguments should be discoverable at the server side.

This only requires a few changes, mainly to ssh. Alternatively, we could move to a JSON (or JSON-based) approach: Each command has a single argument (possibly empty), which consists of a JSON expression.

Both alternatives are equally flexible as I see it.

WireProtocolUnificationPlan (last edited 2012-10-25 21:12:42 by mpm)