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"
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.
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at