D2061: sshpeer: initial definition and implementation of new SSH protocol

[indygreg (Gregory Szorc)]

indygreg added a comment.


  I want to emphasize that I'm not committed to any implementation detail at this point in time. I've very opened minded about alternatives and making backwards incompatible changes throughout the 4.6 release cycle.
  
  That being said, I am trying to make forward progress on a ton of wire protocol changes. These are blocking my planned work for shallow clone this release cycle. (I don't want to deploy shallow clone on the existing wire protocol for various reasons.) So, I would prefer we //fall forward// and take commits even if there are open bikesheds. I'm more than happy to rework the protocol later. I just don't want my local work to be dozens of changesets ahead of what's reviewed and have to spend hours reworking my code because of a bikeshed. I'd rather commit the flawed work, fix it at the head of my local queue, and move forward. If nothing else, this approach will lead to a more feature complete protocol landing sooner. And only once it is feature complete will we all have the full perspective to bikeshed the protocol.

INLINE COMMENTS

> wireprotocol.txt:241-243
> +The transport capabilities string is a URL/percent encoded string
> +containing key-value pairs defining the client's transport-level
> +capabilities. The following capabilities are defined:

I chose the //query string// format here because I don't like reinventing wheels. However, if we wanted to make it a list of space delimited atoms (like the existing capabilities string), I'd be OK with that.

We can always change this later, since we're not locked into any BC guarantees at this juncture.

> wireprotocol.txt:245-247
> +proto
> +   A comma-delimited list of transport protocol versions the client
> +   supports. e.g. ``ssh-v2``.

In the future, I want to advertise:

- compression engine support
- compression engine settings (e.g. max window size for zstandard so a server won't choose a compression level that will result in excessive memory usage for client)
- max concurrent responses limit (in the future, the protocol will gain the ability to stream multiple responses for a single request concurrently)

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D2061

To: indygreg, #hg-reviewers
Cc: mercurial-devel