I have question regarding the future direction of protocol buffers.
Is Google planning on adding features or changing the encoding of data
types in any way that would break backwards compatibility?  I've read
through the posts and it appears that the developers will try to
maintain compatibility as much as possible.  My primary concern is
that I plan on using a header message type that includes various
fields to describe the next message including type and size.  Because
I would be using fixed integer sizes (no varints) in the header, I
will know in advance the size of the header therefore I wouldn't need
to give the size in the stream.  However, this makes the assumption
that future version of Protocol Buffers will not change the size of
the serialized header or the individual fields.   Since the header has
more than just size data information, I would prefer to use a protocol
buffer message instead of straight binary as it makes it easier for
languages that do not make it easy to convert binary to native data
types and removes concerns about endianness and data type sizes (work
is already done for me).  My other option is use text strings as
almost all languages make it simple to convert strings to native data
types, but I would prefer to keep the wire protocol "pure".  Some of
my fellow developers also have concerns about freezing development to
one particular version of protocol buffers.  How realistic is it to
expect the encoding and size of this type of message to remain
unchanged or infrequently changed?
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to