After playing with protobuf for the last few months, I've decided that
it's not quite suitable for my purposes, due to some design decisions
(which I'm sure seemed the like a good idea at the time).  As much as
I hate reinventing the wheel, I've decided to create my own message
encoding framework implementing the features below ("And blackjack!
And hookers!  Ah, who needs the framework"), while maintaining wire-
level compatibility with protobuf.

1. XML vs. Yet-Another-Proprietary-File-Format
The arguments against using XML at the wire-level are well documented,
but why, oh why, couldn't you have made the message definition format
(.proto) XML-based?  Now every language has to code and debug (!)
their own parser, and there's no way to add meta-data to the message
definitions.  What's wrong with just publishing a DTD/XSchema and
using an off-the-shelf XML parser?

This is my single biggest complaint, and the one reason protobuf is
unsuitable for my project:  the message definitions need to include
enough information to dynamically generate the user interface for both
displaying and composing messages.

2. Message Inheritance (vs. Extensions?)
Are there any languages left that don't support single-inheritance,
even C?  Reserving a zero'th message field for a base message class
uses almost no overhead, and allows for a nice message class

Perhaps I just don't grok Extensions, but they seem more like a safety
feature than a re-usability mechanism.

3. Typedefs
E.g., "UUID=string", "Timestamp=double", etc.  Syntactic sugar is
always good.

4. Built-un UUID Type
There are lots of other built-in types I'd like to have, but I think
this one's a must for a message encoder.

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at

Reply via email to