New msgpack spec

[Paul Colomiets]

Hi,

I noticed that new opcodes have been recently added in msgpack.

The ones for binary data type: 0xc4-0xc6, and the ones for ext data type.

It seems not all bindings are updated. My personal interest is python
bindings. Should I make a pull request? If I should (in case spec is
not experimental, and nobody is working on that already), I want to
know:

1. What upgrade path is recommended? I.e. I think there are users who
store binary data in old "raw" type. Should there be a flag in
unpacker to unpack the old way?

2. How to handle ext data type? Should it work only on subclasses of
unpacker? Also how should hooks look like? (or how they look like in
other language bindings)

BTW, I'm very optimistic about the changes, especially about
separation of string and binary types.

Thanks
--
Paul

[INADA Naoki]

Hi, Paul. I'm msgpack-python maintainer.

I'm sorry about delay about implementing new spec.

I don't have any time at least untill PyCon APAC.

I'll support new spec in this year.

On Fri, Aug 30, 2013 at 5:40 AM, Paul Colomiets <pa...@colomiets.name> wrote:

Hi,

I noticed that new opcodes have been recently added in msgpack.

The ones for binary data type: 0xc4-0xc6, and the ones for ext data type.

It seems not all bindings are updated. My personal interest is python
bindings. Should I make a pull request? If I should (in case spec is
not experimental, and nobody is working on that already), I want to
know:

1. What upgrade path is recommended? I.e. I think there are users who
store binary data in old "raw" type. Should there be a flag in
unpacker to unpack the old way?

New spec doesn't prohibit storing binary data to "raw" for backward compatibility.

I'll add flag to use new spec on Packer and Unpacker.

It will be off by default for backward compatibility and interoperability.

 

2. How to handle ext data type? Should it work only on subclasses of
unpacker? Also how should hooks look like? (or how they look like in
other language bindings)

I don't have decided design for now.

My suggestion is adding ExtType class. Packer and Unpacker use it by default.

And add ext_type_map option to Packer and Unpacker.

class MyType(object):

    def __init__(self, n):

        self.n = n

packed = msgpack.packb(datetime.datetime.now(),

    ext_type_map={MyType: (42, lambda x: msgpack.packb(x.n))})  # {Type: (ext no, encoder)}

msgpack.unpackb(packed,

    ext_type_map={42: lambda d: MyType(msgpack.unpackb(d))})  # {ext no, decoder}

 

BTW, I'm very optimistic about the changes, especially about
separation of string and binary types.

Thanks

--
Paul

--
You received this message because you are subscribed to the Google Groups "MessagePack Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msgpack-dev...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
INADA Naoki  <songof...@gmail.com>