On Tue, Feb 8, 2011 at 11:23 AM, Evan Jones wrote:
> Sorry, just an example of why you might want a different protocol. If I've
> streamed 10e9 messages to disk, I don't want this stream to break if there
> is some weird corruption in the middle, so I want some protocol that can
> "resume" from c
On Feb 8, 2011, at 13:34 , Kenton Varda wrote:
I handle user messages by passing them as "bytes", embedded in my
own outer message.
This is what I do as well, as does protobuf-socket-rpc:
http://code.google.com/p/protobuf-socket-rpc/source/browse/trunk/proto/rpc.proto
I guess I was thinking
On Tue, Feb 8, 2011 at 5:47 AM, Evan Jones wrote:
> I read this proposal somewhat carefully, and thought about it for a couple
> days.
Thanks for the feedback!
> * It seems to me that this will solve the problem for people who know
> statically at compile time what types they need to handle f
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
Hello open source protobuf users,
*Background*
Probably the biggest deficiency in the open source protocol buffers
libraries today is a lack of built-in support for handling streams of
messages. True, it's not too hard for users to support it manually, by
prefixing each message with its size as
