Backward Compatibility

407 views
Skip to first unread message

ser...@sergejmueller.com

unread,
May 9, 2011, 10:03:27 AM5/9/11
to MessagePack Users
Hi,
I was wondering how backward compatibility is managed in MessagePack.
In the Overview you state:

>> The MessagePack format contains the type information
>> inside the serialized data along with the data itself.

But describing only the type of a field is not sufficient for backward
compatibility when existing fields are removed or new fields are
added.

Probobuf solves this problem by assigning a key to each fields. The
key denotes the 'meaning' of the field and acts like an unique field
name across all clients. But I couldn't see any hint in MessagePack
for a similar purpose.

Protobuf exmaple:
message Person {
optional string name = 1;
}

Thanks,
—SERGEJ

FURUHASHI Sadayuki

unread,
May 9, 2011, 12:58:50 PM5/9/11
to msg...@googlegroups.com
Hi,

First of all, MessagePack can represent same message with Protocol Buffers in the serialized binary.
Protobuf saves field id instead of field name. Thus the message becomes a id-value map like MESSAGE(1=>"m", 2=>24) in the serialized data. Thrift also uses a map.
MessagePack uses an array like ["m", 24], and the index of elements indicates the field id. Both of them represents almost same data and includes no 'meaning' of the field.

It's provided by the IDL maintained in the separated file:
message PersonInfo {
required string sex = 1;
optional int age = 2;
}

On MessagePack, I started implementation of the IDL last month.
The repository is at https://github.com/msgpack/msgpack-idl

The example above becomes like below:
message PersonInfo {
1: string sex
2: optional int age
}

You can try the first release as follows:
$ gem install msgpack-idl # it's written in Ruby
$ msgpack-idl --install java # only Java generator is provided for now
$ msgpack-idl --example 'types' > types.msgspec
$ msgpack-idl -g java types.msgspec

I will add 'inheritance' of the messages, versioning of RPC and namespace of RPC to the IDL.

Thanks,
Sadayuki

Reply all
Reply to author
Forward
0 new messages