On Sep 9, 9:25 am, Jon Skeet <[EMAIL PROTECTED]> wrote:
> > As for mixing message types in a stream, I think the ability to have a
> > heterogeneous stream (or a stream embedded in another protocol) will
> > be needed by someone.  So the main question, like with delimited
> > messages, is whether each application invents its own technique.  One
> > could use a serialized DescriptorProto Message to announce the type
> > before each message.  All the fields are optional, so the herald
> > message needs only to set the name field.  Or perhaps serialize a
> > (nearly empty) FileDescriptorProto with the (nearly empty) embedded
> > DescriptorProto would make it more clear which object is being
> > serialized.  But this is getting me off track.
>
> I think it's best to concentrate on the simple requirement first, and
> not guess too much about what would be needed. Use cases for an
> homogenous stream are easy to come up with - the simplest being
> logging, for example.

I've just thought of a nice way to do this: provide a message
descriptor which would describe how the whole data could be observed
as a single message. This is backwardly compatible with my current
streaming API (which is still open to change, btw). You'd then iterate
through and get a sequence of field/value pairs, where each value is
of the correct type for the corresponding field in the "umbrella"
message.

Basically this is a "pull" version of the Observer pattern which has
been mentioned before.

The only benefit of my current API is that it doesn't require the
"umbrella" message to be defined beforehand.

Jon

--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to