Yes, I was thinking of scalars only. As you point out, scalar types
could be wrapped in messages to emulate the capability. It seems like a
logical extension of the design, although you are right that the
capability certainly isn't a requirement. I was envisioning the
usefulness of a message envelope such as this:
message Envelope {
required fixed64 length = 1;
optional bool complete = 3;
optional string type = 2;
optional bytes content = 4;
}
Envelopes could then be streamed back to back.
The length could be initialized first, using the fact the length field's
fixed byte-count to select it from the stream, and the field's ability
to parse its own value.
Then the remainder of the envelope could be initialized using the
now-known length.
Then the complete flag could be used to determine whether the full
message has been received, or if additional envelopes need to be
aggregated.
Then the message type name could be used to look up and instantiate the
type of message the envelope(s) contained.
Then the message instance could be initialized using the content(s)
collected from the envelope(s).
But it is definitely true that serializing/parsing single fields is not
a requirement. And, for an application such as this, it would be very
easy to define a content-length message to wrap the byte-count in
something that could be parsed independently.
On Tue, 2008-12-02 at 14:46 -0800, Alek Storm wrote:
> As requested, a repost of my earlier message on the original thread:
>
> You're talking about scalar fields, right? Because nested message
> fields can be serialized individually, just like their parents. I
> think it's a cool idea, and it doesn't look that hard to implement,
> but I'm not sure how useful it would be - if you're streaming a
> message, you just need (tag, value) pairs, which is what a full
> message is anyway, so there's no extra overhead. However, streaming
> messages definitely needs to be implemented.
>
> Cheers,
> Alek Storm
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
