On Jan 2, 12:04 pm, jd <unicom...@gmail.com> wrote:

> Any chance we could add delta concept(s) to Protocol Buffers?  This
> would make it more efficient for streaming applications.  See the FIX/
> FAST spec.  Just having presence bits could go a long ways.

I think I accidentally did a Reply To Author on this yesterday.

Being able to access the "_has_bits_" member of the generated Message
classes would give you a lot of what you'd need to implement something
like a FAST presence map with Protocol Buffers, but this member and
its accessors are all private.  There is a corresponding accessor
GeneratedMessageReflection.GetHasBits, but it is similarly private and
seems not to be used anywhere.  You could get this information field-
by-field using Reflection.HasField, but this would likely be a lot
slower than accessing the Message's aggregate bit-vector in a single
operation.

That said, FAST's encoding rules and presence map are a lot less
flexible than POPB (Plain Old Protocol Buffers) in that both reader
and writer need to agree completely on the message template in order
to communicate.  If the writer adds more fields to a message or
changes the encoding rule used for a field, the receiver will never be
able to properly decode the new message format until they get the
updated templates.  This may be fine for some use-cases, but I believe
Protocol Buffers is intended to be less brittle than that.

Another shortcoming of FAST, especially when all of the 1.1 features
are used, is the complexity of decoding the stream.  Optional delta-
encoded decimal fields anyone?  Shudder.

I also dislike the fact that, by default, messages are not length-
encoded.  This makes skipping to the end of a message (e.g. if you
decide you are not interested in it while parsing a larger aggregate
packet) requires executing all of the instructions for the entire
message in order to reach its end.  Protocol Buffers doesn't have any
length-encoding out-of-the-box either, but I always length-encode
individual messages when combining them in a larger packet to make
skip-to-end O(1).
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to