Gregory Szorc <gregory.szorc@gmail.com> [Sat, 14 Apr 2018 12:07:31 -0700] rev 37722
wireprotov2: define response data as CBOR
Previously, response data was defined as a stream of bytes. We had
the option to declare it as CBOR using a frame flag.
We've converged all wire protocol commands exposed on version 2 to
CBOR. I think consistency is important. The overhead to encoding
things with CBOR is minimal. Even a very large bytestring can be
efficiently encoded using an indefinite length bytestring. Now,
there are limitations with consumers not being able to efficiently
stream large CBOR values. But these feel like solvable problems.
This commit removes the "is CBOR" frame flag from command response
frames and defines the frame as always consisting of a stream of
CBOR values.
The framing protocol media type has been bumped to reflect this
BC change.
Differential Revision: https://phab.mercurial-scm.org/D3382
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 14 Apr 2018 11:49:06 -0700] rev 37721
wireprotov2: decode responses to their expected types
Callers of established wire protocol commands expect the
response from that command to be decoded into a data structure.
It's not very useful if callers get back a stream of bytes and
don't know how they should be interpreted - especially since that
stream of bytes varies by wire protocol and even the transport
within that protocol version.
This commit establishes decoding functions for various command
responses so callers of those commands get the response type
they expect.
In theory, this should make the version 2 HTTP peer usable for
various operations. But I haven't tested to confirm.
Differential Revision: https://phab.mercurial-scm.org/D3381
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 14 Apr 2018 11:46:08 -0700] rev 37720
wireprotov2: establish a type for representing command response
It will be desirable to have a higher-level type for representing
command responses. This will allow us to do nicer things.
For now, the instance encapsulates existing logic. It is still
a bit primitive. But we're slowly making things better.
Version 1 protocols have a wrapping layer that decodes the raw
string data into a data structure and that data structure is
sent to the future. Version 2 doesn't yet have this layer and
the future is receiving the raw wire response. Hence why
debugcommands needed to be taught about the response type.
Differential Revision: https://phab.mercurial-scm.org/D3380