Ouch, this hole is probably a lot deeper than it looks. First let me review some things which you may already know...
I assume these "plugins" are DLLs. Do you load and unload these plugins at runtime, or just at startup? If you unload them at runtime, then each one needs to be statically linked against its own instance of the protobuf library (probably the lite library!), because libprotobuf is not designed to allow individual protos to be unloaded without shutting down the entire library. But if each plugin has its own instance, then you cannot pass protobuf objects to the plugin. You can only pass encoded messages, which it must parse itself. If you do load the plugins for the entire life of the process, then things are a little more flexible. In this case, you can share a single instance of libprotobuf among all of them and your app as long as everyone links against it as a DLL. (Though, in this case all plugins must be linked against the exact same version of libprotobuf, which may be a problem if they are developed by separate groups.) Now, getting back to extensions, if you are going with the first option, then obviously your app can recognize extensions defined within the plugins, because they use a separate instance of libprotobuf. But it doesn't matter, because you have to re-serialize the messages before sending them to the plugins anyway, and they will do their own parsing with the extensions recognized. If you are going with the second option (sharing a common instance of libprotobuf), then the plugin *should* have registered its extensions with that common instance at startup, and therefore it should be parsing correctly. To answer your specific question, BTW, yes, you can inspect the contents of UnknownFieldSet. Every message object has methods unknown_fields() and mutable_unkown_fields() which return the UnknownFieldSet. The API is described here: http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.unknown_field_set.html On Thu, Aug 27, 2009 at 10:25 PM, Jesper Eskilson <jes...@eskilson.se>wrote: > On Fri, Aug 28, 2009 at 1:28 AM, Kenton Varda<ken...@google.com> wrote: > > Yep, it's a very annoying problem. The solution I prefer is to add a > dummy > > usage of one of the classes in your .proto somewhere high-up in your > > program, in a place that should logically "know" that the file is needed. > > This is really not feasible. There is no such place, unfortunately. > > > BTW, if you aren't actually explicitly using the extension anywhere, then > > the only reason to force it to be linked in is if you want it to appear > > correctly when using reflection or TextFormat. Otherwise you should just > > let it go into the UnknownFieldSet. > > The situation is this: I have a main program which parses incoming > messages, and some of these messages have extensions set. These > extensions are (sometimes) only known to "plugins" to the main > program. The incoming message has an identifier so that the main > program knows which plugin it should send the message to, but the main > program itself doesn't know anything about the plugin. The problem I > had was that when the message was passed to the plugin, the plugin > fails to get the extension, i.e. the extension field was unset (i.e. > HasExtension(foo::foo_ext) returned false). > > Does the UnknownFieldSet allow the plugin to extract the "unknown field"? > > The original solution to this I had before I read up on extensions was > to store the messages to/from the plugins as seralized byte-streams in > the top-level package. This actually worked fine, with the exception > of having to encode/copy the message twice at both ends. > > -- > /Jesper > --~--~---------~--~----~------------~-------~--~----~ 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 protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---
