Please re-send your question to the appropriate Google-internal mailing
list. is populated by people who are not Google
employees and is not an appropriate place to discuss internal code or
documentation.  Luckily your message doesn't contain anything sensitive, but
since you're discussing the version 1 implementation of Protocol Buffers,
which is not public, and posting links to internal documents, you should
really be using an internal list.

On Tue, Sep 23, 2008 at 3:20 PM, svenkata <[EMAIL PROTECTED]> wrote:

> In one place in production code, we used ToASCII and ParseASCII APIs
> to encode and decode a protocol message.
> The previous implementer had a comment on the usage of ASCII:
> // The protocol buffer is converted into an
> // ascii version so that a big endian transmitter can talk to a little
> // endian receiver and vice versa. This will change once the protocol
> // buffer implementation is ported to work with a neutral wire format.
> First question: Does the protocol buffer implementation support
> neutral format now? In other words, does two machines with different
> endians talk to each other (encode and decode) via protocol buffers.
> I added couple of new optional field to the old protocol buffers. I'm
> seeing a problem with backward compatibility.  That is old code is
> complaining that the new fields are unrecognized:
> 09-21-2008 06:25:12 XX ygs04f1s2i30 user.err lcm[846]: tagmapper-
>] Did not find tag type in message type IfmNDMessage
> 09-21-2008 06:25:12 XX ygs04f1s2i30 user.err lcm[846]: tagmapper-
>] input error at line: 7 column: 1: ParseSlot(group_name)
> failed
> Here is what I found after close reading:
> Extending a Protocol
> ...
> Also, make any new elements and groups be optional or repeated, so
> that messages generated by old code can be parsed by new code. As
> noted above, the old code will ignore any unknown elements in the
> message.
> ...
> ASCII Format
> ...
> Support is provided for converting from ASCII to binary with the
> ParseASCII method. As this support is slow and does not allow
> evolution of protocol types its use is discouraged for production
> services.
> ...
> Second question: What does it mean "does not allow evolution of
> protocol types" in the above doc? Does it mean ToASCII and ParseASCII
> methods are not backward compatible?
> Third question: How should I correct this now? The protocol message to
> which I added optional fields (call it FooMessage) is embedded inside
> other message (call it BarMessage) as a required field of type string.
> Because it is a string, the previous author used ToASCII and
> ParseASCII. Now I can't change this string to FooMessage because it is
> a required field in production.
> >

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at

Reply via email to