[PATCH 1 of 4] wireproto: add basic command batching infrastructure
peter.arrenbrecht at gmail.com
Thu Jun 16 07:20:57 CDT 2011
On Thu, Jun 16, 2011 at 5:52 AM, timeless <timeless at gmail.com> wrote:
> On Tue, Jun 14, 2011 at 4:59 PM, Peter Arrenbrecht
> <peter.arrenbrecht at gmail.com> wrote:
>> + All methods invoked on instances of this class are simply queued and return a
>> + a future for the result.
> i think you should write 'a `future` as the result'
The idea is that you'll query the 'future' eventually for the actual
result. But whatever. If you care deeply enough, feel free to submit a
> i'm not a fan of 'future', is it an object? i can't tell from this.
It's a fairly established term for a thing that you get back from a
call immediately with the promise that, when you access the thing's
value later, it will hold the actual result of the call. So it's
sometimes called a 'promise', too.
All the other nits below are in test code. So while I appreciate your
help in polishing my English, I won't bother to submit a patch.
>> +# demo remoting; mimicks what wireproto and HTTP/SSH do
>> +# equivalent of wireproto.encode/decodelist, that is, type-specific marshalling
>> + # greet is coded directly. It therefore does not support batching. If it
>> + # does appear in a batch, the batch is split around greet, and the call to
>> + # greet is done in its own roundtrip.
More information about the Mercurial-devel