[PATCH 7 of 9 RFC] pushkey: support for encoding and decoding raw listkeys dicts

Pierre-Yves David pierre-yves.david at ens-lyon.org
Tue Aug 16 20:03:45 EDT 2016



On 08/16/2016 03:57 PM, Yuya Nishihara wrote:
> On Sun, 14 Aug 2016 14:10:06 -0700, Gregory Szorc wrote:
>> # HG changeset patch
>> # User Gregory Szorc <gregory.szorc at gmail.com>
>> # Date 1471207500 25200
>> #      Sun Aug 14 13:45:00 2016 -0700
>> # Node ID eb2bc1ac7869ad255965d16004524a95cea83c9d
>> # Parent  1fe812eb8b9e79d1182c4a6593e7ce8fa2938264
>> pushkey: support for encoding and decoding raw listkeys dicts
>
>> +def encodekeysraw(keys):
>> +    """Encode pushkey namespace keys using a binary encoding.
>> +
>> +    The response consists of framed data packets of the form:
>> +
>> +        <size> <data>
>> +
>> +    Where the ``size`` is a little endian 32-bit integer.
>> +
>> +    Data is emitted in pairs of frames where the first frame is the key
>> +    name and the second frame is the value.
>> +
>> +    A frame with size 0 indicates end of stream.
>> +    """
>> +    s = struct.struct('<I')
>> +
>> +    chunks = []
>> +    for k, v in keys:
>> +        assert not isinstance(k, encoding.localstr)
>> +        assert not isinstance(v, encoding.localstr)
>> +
>> +        chunks.append(s.pack(len(k)))
>> +        chunks.append(k)
>> +        chunks.append(s.pack(len(v)))
>> +        chunks.append(v)
>
> I heard we should stick to big endian. The cost of byte-order conversion
> should be pretty cheap.
>
> And if we're trying to reduce the payload size, it might be too large to
> add 4-byte length field for each key/value pair.

yeah, all our network protocol is big endian.
(but also see my comment about using bundle2 instead of direct listkey here)

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list