Ah, I see. How about if we just extend parseDelimited() to return null at EOF?
On Tue, Jun 9, 2009 at 12:36 PM, Jon Skeet <sk...@pobox.com> wrote: > > On Jun 9, 8:28 pm, Kenton Varda <ken...@google.com> wrote: > > I still think that this doesn't belong in the scope of protocol buffers, > but > > rather some higher-level utility library. > > Doesn't that make writeDelimited/parseDelimited somewhat less useful > then? You can write as many messages as you like to a file, but you > don't know when you've finished reading them... > > I can see the argument for keeping these things in a higher-level > utility library, but we've done *half* the job in PBs now (without > giving enough information to finish the job elegantly). > > > That said, what does your proposal offer over the > > writeDelimited/parseDelimited methods added to the Java runtime in 2.1.0? > > (Still need to add them to C++ and Python...) > > I'm talking about making exactly those methods more useful. > Ironically, my C# port already has a separate way of writing a > "message stream" and iterating over it, based on a previous discussion > - basically we write individual messages as if they were repeated > fields of some container message. (Pleasantly, if you then define such > a container message, you can just read a file written by > MessageStreamWriter as an instance of that container.) In that case, I > just call readTag until it returns 0... but there's no equivalent for > writeDelimited/parseDelimited. ParseDelimited will either return a > newly built message, or throw an exception if it encounters bad data > or the end of the file. In particular, there's no way of telling the > difference between a file that finished correctly at the end of a > message and a file that contains "half a message" (or half a message > *size*) at the end. > > To put it another way: if you don't know how many messages have been > written to a file, how would you propose reading them with the current > API? I suppose you could wrap the stream in a PushBackInputStream, and > between each message read the next byte and either finish if you > detect the end of the stream, or push the byte back and read another > message otherwise. I'd like to think we can do better than that > though :) > > Jon > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
