[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