Sun, 15 Apr 2018 10:37:29 -0700 wireprotov2: add support for more response types
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 15 Apr 2018 10:37:29 -0700] rev 37728
wireprotov2: add support for more response types This adds types to represent error and generator responses from server commands. Differential Revision: https://phab.mercurial-scm.org/D3388
Sat, 14 Apr 2018 15:38:11 -0700 wireprotov2: remove support for sending bytes response
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 14 Apr 2018 15:38:11 -0700] rev 37727
wireprotov2: remove support for sending bytes response We recently declared that all responses must be CBOR. So remove support for sending a type that isn't CBOR data. Differential Revision: https://phab.mercurial-scm.org/D3387
Sat, 14 Apr 2018 15:36:12 -0700 wireprotov2: change behavior of error frame
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 14 Apr 2018 15:36:12 -0700] rev 37726
wireprotov2: change behavior of error frame Now that we have a leading CBOR map in command response frames to indicate overall command result status, we don't need to use the error response frame to represent command errors. Instead, we can reserve it for protocol and server level errors. And for the special case of a command error that occurred after command response frames were emitted. The code for error handling still needs a ton of work. But we're slowly going in the right direction... Differential Revision: https://phab.mercurial-scm.org/D3386
Sat, 14 Apr 2018 15:19:36 -0700 wireprotov2: change command response protocol to include a leading map
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 14 Apr 2018 15:19:36 -0700] rev 37725
wireprotov2: change command response protocol to include a leading map The error handling mechanism for the new wire protocol isn't very well-defined. This commit takes us a step in the right direction by introducing a leading CBOR map for command responses. This map will contain an overall result of the command. Currently, the map indicates whether the command was overall successful or if an error occurred. And if an error occurred, that error is present in the map. There is still a dedicated error frame. My intent is to use that for protocol-level errors and for errors that are encountered after the initial response frame has been sent. This will be clarified in a later commit. Differential Revision: https://phab.mercurial-scm.org/D3385
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 +10000 tip