[PATCH 1 of 4] wireproto: add basic command batching infrastructure

Peter Arrenbrecht 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
patch.

> 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.
-parren

>> +# demo remoting; mimicks what wireproto and HTTP/SSH do
>
> mimics
>
>> +# equivalent of wireproto.encode/decodelist, that is, type-specific marshalling
>
> marshaling
>
>> +    # 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.
>
> round-trip?
>


More information about the Mercurial-devel mailing list