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.

Reply via email to