[PATCH 7 of 9 RFC] pushkey: support for encoding and decoding raw listkeys dicts
Yuya Nishihara
yuya at tcha.org
Tue Aug 16 09:57:52 EDT 2016
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.
More information about the Mercurial-devel
mailing list