State of protocol changes; naming contest

Sune Foldager cryo at cyanite.org
Sat Feb 20 09:24:07 CST 2010


Hey guys

As you may know I have been working on some changes to the two write
protocols (low-level changes; not command set), ssh and http to bring
their feature set more in-line. Http is missing better transfer of
hook-output and sometimes errors back to the client; ssh is missing
arbitrary number of arguments for commands.

Also, we want to add some features to the high-level protocol in the
near future: parent-delta, light-weight copy, new discovery. For these
things we are going to need some capabilities, so the client knows what
the server understands. For some things we also need a few other tweaks
which are not finalized yet.

The protocol changes for ssh necessitates a new capability on two
levels: low-level (the command format changes) and high-level (the
features mentioned above). The http protocol only needs capabilities for
the high-level changes, since the command format stays the same. Thus we
have the following decisions to make:

a) Do we use the same capability names for ssh and http? I personally
think we should.

b) Do we use separate capabilities for each of the high-level features,
or lump them together in a single one? I think I prefer the latter, to
avoid making the code too complex.

c) Do we use a separate capability for the new ssh command format, or
lump it together with the one from b (assuming we decided to lump those
together; otherwise we need a separate one I guess). I am not sure about
this one. It's somewhat a conflation of domains. On the other hand, we
don't really need the feature on its own.

d) What do we call the capabilities? Some possibilities: "protocol=2"
(pro: easy to extend later on. con: kind of conflicts with the 0.1 that
http uses, but which isn't _really_ used). "<foo>ng" (this one's for
mpm). "lwpddisco".. ok that's silly, but illustrates how hard it is to
find a suitable name :).

Let's have some feedback on the above points :)

/Sune


More information about the Mercurial-devel mailing list