I'm interested in Josh's project not so much for the streaming or
partial parsing ability, but for his use of the word 'callback'. In my
system, I am using PB not only for passing data back and forth, but
also as a data store object in the object that is receiving a PB
message. There are specific actions that need to occur when a message
field changes, whether it's via a set or a parse method. I'd like the
ability to automatically perform these actions. I was wondering if
Josh's project is hoping to address this need. I looked at his code
today and didn't see any indication of this.
Also, Is anyone else using PB in this way?
On Feb 23, 1:33 pm, Joshua Haberman <jhaber...@gmail.com> wrote:
> On Feb 23, 9:51 am, Caleb <caleb.epst...@gmail.com> wrote:
> > On Feb 6, 5:56 pm, Joshua Haberman <jhaber...@gmail.com> wrote:
> > > Does proto2 support event-based decoding? That is, is there a parsing
> > > mode that calls user-specified callbacks when it encounters values/
> > > submessages/etc. rather than automatically putting all the data into
> > > an in-memory data structure? If so, is this supported for both
> > > generated classes and .proto files that are loaded at runtime?
> > > Also, does it support streaming decoding? That is, can you parse a
> > > partial protobuf (which may or may not end on a record boundary), then
> > > parse more data as more becomes available?
> > > I ask because I'm working on a minimalist C implementation that
> > > specifically targets these use cases. I'm just curious if proto2
> > > supports these use cases too.
> > > I'm planning to finally release my implementation soon. It's not
> > > ready yet, but for anyone who wants to check it out, see:
> > >http://github.com/haberman/pbstream
> > Neat stuff. It would be very interesting to benchmark this against
> > generated Protocol Buffers deserialization code, which does use some
> > neat tricks (I love the fast-path code using gotos) but may suffer
> > performace-wise when you start processing nested messages and optional
> > fields that all end up on the heap.
> Right, I fully suspect that my implementation will win if you're just
> parsing and not saving the data to another data structure. And as far
> as the fast-path goto code, I'm starting to suspect that the
> performance gap here may not be as big as one might think.
> > Have you implemented the parser interface yet? These functions
> > pbstream_init_parser and pbstream_parse are missing from the github
> > code.
> Yeah, there's a lot missing and it doesn't work yet. But I'm working
> on it feverishly and hoping to release it sometime soon.
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to
For more options, visit this group at