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? Tim 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 protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---
