I read this proposal somewhat carefully, and thought about it for a
couple days. I think something like this might solve the problem that
many people have with streams of messages. However, I was wondering a
couple things about the design:
* It seems to me that this will solve the problem for people who know
statically at compile time what types they need to handle from a
stream, so they can define the "stream type" appropriately. Will users
find themselves running into the case where they need to handle
"generic" messages, and end up needing to "roll their own" stream
support anyway?
I ask this question because I built my own RPC system on top of
protocol buffers, and in this domain it is useful to be able to pass
"unknown" messages around, typically as unparsed byte strings. Hence,
this streams proposal wouldn't be useful to me, so I'm just wondering:
am I an anomaly here, or could it be that many applications will find
themselves needing to handle "any" protocol buffer message in their
streams?
The Visitor class has two standard implementations: "Writer" and
"Filler". MyStream::Writer writes the visited fields to a
CodedOutputStream, using the same wire format as would be used to
encode MyStream as one big message.
Imagine I wanted a different protocol. Eg. I want something that
checksums each message, or maybe compresses them, etc. Will I need to
subclass MessageType::Visitor for each stream that I want to encode?
Or will I need to change the code generator? Maybe this is an unusual
enough need that the design doesn't need to be flexible enough to
handle this, but it is worth thinking about a little, since features
like being able to detect broken streams and "resume" in the middle
are useful.
Thanks!
Evan
--
http://evanjones.ca/
--
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.