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- ascii.cc:388] Did not find tag type in message type IfmNDMessage 09-21-2008 06:25:12 XX ygs04f1s2i30 user.err lcm[846]: tagmapper- ascii.cc:254] input error at line: 7 column: 1: ParseSlot(group_name) failed Here is what I found after close reading: https://www.corp.google.com/eng/designdocs/infrastructure/protocol-buffer.html 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 protobuf@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---
