Thats a great help thanks.
Yeah I was thinking at the end of yesterday after playing with the
UnknownFieldSet that the serialization is very tight / concise to just
tags, makes sense really given what its doing.
Been thinking about it this morning, probably going to go with the
envelope way as I can specify a target module and sub id that way in 2
strings. That way I can guarantee messages will not conflict between
modules and just thinking about it now, means I can develop a small
library of "standard" messages that modules can reuse if need be + the
server would be able to deliver / handle them correctly (i.e. the
destination is not based on the descriptor, probably a good
thing :P).
Yeah the dynamic stuff seemed a little messy, especially the bit about
at the bottom bit "the reason that this functionality is not included
in the Protocol Buffer library is because we have never had a use for
it inside Google" -- I'm thinking there are good reasons why they dont
use it :P
Sorted, thanks again!
Jon
On Oct 19, 7:40 pm, Kenton Varda <ken...@google.com> wrote:
> On Tue, Oct 19, 2010 at 8:17 AM, jon.mithe <jon.mi...@gmail.com> wrote:
> > Hi,
>
> > I am thinking about using the protocol buffers over XML for a server I
> > am writing.
>
> > Is there a way to pick up on what message type / descriptor it is
> > without using the specific compiled .proto implementation?
>
> No. By design, no type information is included in the message, and the
> encoding is so dense that it is often impossible to reliably distinguish the
> type.
>
> > The server needs to be very flexible / modular. So I was hoping to
> > develop modules of functionality, each defining there own .proto
> > messages. Then have a simple incoming connection which can
> > effectively inspect / pass these messages onto a matching handler in
> > whatever module owns that message.
>
> You may want to create an "envelope" message type which helps your server
> route messages without having to parse the message contents. Example:
>
> message Envelope {
> optional string destination = 1;
> optional bytes real_message = 2;
> }
>
> The server receives Envelopes and sends them to the correct module based
> only on "destination". The module then knows how to parse its own messages.
>
> > I can include descriptor/typing information in the stream to the
> > server to match the handler, but was hoping / thought the google
> > protocol library may have some ways to poke at the messages -- have
> > not found any yet.
>
> Yes, you can do that.
> See:http://code.google.com/apis/protocolbuffers/docs/techniques.html#self...
>
> > Been reading about the reflection on Messages, but seems like this
> > just for a parsed message to inspect it in a generic / abstract way,
> > i.e. not like java reflection which is more what I need to id a
> > message but I parse it properly.
>
> Once you have a Descriptor, you can construct a DynamicMessage and parse
> into that. You can then use protobuf reflection on the DynamicMessage.
--
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.
