I thought the group is internal. But (whether you noticed or not) I removed my first message and sent out another one. Thanks for pointing this out.
On Tue, Sep 23, 2008 at 3:50 PM, Kenton Varda <[EMAIL PROTECTED]> wrote: > Please re-send your question to the appropriate Google-internal mailing > list. [email protected] 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- >> 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
