The main concern with text format is that it doesn't have nearly as good backwards- and forwards- compatibility as the binary format. E.g. what happens if you release your program, and then in a future update want to remove or rename a field? The new binary format code would have no trouble reading the existing data, but if the existing data was in text format it would be a problem.
On Sat, Dec 10, 2011 at 11:05 AM, Tom Swirly <tom.ritchf...@gmail.com>wrote: > Hello, proto-people. I suspect some of you know me already... > > I'm just finishing a moderately large project that makes extensive use of > protocol buffers as a storage format for data files for a consumer desktop > application. (The protos are working extremely well, of course, and I have > a really slick object-oriented persistence mechanism with them that's > really useful, but that's for another day). > > I have a flag that lets me store the protocol buffers either as text > (using the Print* and Parse* methods from google::protobuf::TextFormat) or > serialized. It's of course much easier to keep them as text when I'm > developing, and since the files are pretty tiny (though there are a lot of > them) I'm thinking of keeping them as text files even for the first public > release. > > But this got me thinking. If I see a file I haven't seen before that > might be either a binary proto or a text proto, why can't I try to parse it > as text, and then if that fails, as binary? > > Yes, yes, this has some spiritual dubiousness. Nothing in the proto > definition precludes the idea that the binary form of one proto buffer > cannot be the text form of another. > > And there's certainly the case of the "empty file" - which could either be > the text string representing the default protocol buffer, or the binary > string representing that same protocol buffer. But in that case, I don't > care. > > But practically speaking, I don't see how this would not work. If I try > to read a binary format as text, then Between the wire types and my > protocol buffer field IDs (which are all less than 32), the text parsing > has to run into an unprintable byte very soon and terminate... > > Am I right? It's not a big deal if not... > > -- > You received this message because you are subscribed to the Google Groups > "Protocol Buffers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/protobuf/-/yYNE3tPUtcgJ. > 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. > -- 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.