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.
> Josh
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 
For more options, visit this group at 

Reply via email to