On Fri, Sep 25, 2009 at 1:28 PM, dound <doun...@gmail.com> wrote: > 1) An option to prefix a length field to each message. This would > make it possible to serialize/deserialize a stream of bytes (e.g., a > TCP socket). >
We consider it the responsibility of the transport to maintain the message's size. Almost all transports (e.g. HTTP) already have a mechanism for doing this. Furthermore, it's clear that any high-level transport for messages composed of raw bytes *has to* have its own mechanism for encoding the size of the message because relying on the raw bytes to provide their own mechanism is obviously unworkable. So, it is only when writing messages to raw sockets (or other simple data streams) that you need a length prefix. I think a lot of people start out by trying this, which is why we get this question fairly frequently. However, you will quickly find that this technique is insufficient for any real application. All that said, in java there are the writeDelimitedTo() and parseDelimitedFrom() methods which do what you want. I'm happy to accept patches to add equivalent methods to C++ and Python. > 2) An option for prefixing a type field to each message -- this makes > it possible to tell what message type is coming over a stream of > bytes. This is useful in some cases where you expect a message but > don't know what kind. > See: http://code.google.com/apis/protocolbuffers/docs/techniques.html#union <http://code.google.com/apis/protocolbuffers/docs/techniques.html#union> --~--~---------~--~----~------------~-------~--~----~ 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 protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---
