On Sep 10, 7:10 pm, Jason Hsueh <jas...@google.com> wrote: > Can you provide a small reproduction of the problem? A couple common errors: > - custom options need to be specified as "option (<option_name>) = <value>;" > (parentheses around the identifier) > - if you're using the option in a different package than the one in which > its defined, it needs to be qualified with the package name
Yes, I'm pretty sure I followed the instructions in the documentation. > Also, note that protocol buffers were originally designed to get away from > having to deal with version numbers (see "A bit of > history":http://code.google.com/apis/protocolbuffers/docs/overview.html) > Typically, > you would define your protocol in such a way that different versions are > still compatible. When that's not practical/possible, people may just switch > to entirely new messages. We have a Java-program A which spawns a C++-program B, and A needs to know that B can deal with the messages it sends, and if new functionality in the protocol is added, A needs to be able to figure out if B is sufficiently new to handle the new functionality. So this is strictly not so much a protocol version, but rather a program version. I solved this by having one version number encoded in the C++-program and another in the Java-program, and a version-message is exchanged when they hook up. If B does not present a new enough version number, the program is terminated. The only drawback is that I have to change the version number in two places when adding functionality to the protocol. -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.