On Nov 8, 2:06 pm, Kenton Varda [EMAIL PROTECTED] wrote:
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?
Because XML is too verbose and, frankly, really hard to read.
message name=Foo
field name=foo number=1 type=int32 label=optional/
field name=bar number=2 type=string label=repeated/
/message
vs.
message Foo {
optional int32 foo = 1;
optional string bar = 2;
}
I agree - both PB XML are machine parsable, but PB is much more
human parsable. Maybe some people really like reading XML, but I'm not
a member of that club :-) XML is a tool that is invaluable in some
situations, but it is inappropriate to try and apply it to everything.
As another poster has suggested, you can convert proto files into XML
then do what you like with them.
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.
You can do this with custom options. For example, to annotate fields with
descriptions for use in a UI:
import google/protobuf/descriptor.proto;
extend google.protobuf.FieldOptions {
optional string description = 12345;
}
message Foo {
optional int32 foo = 1 [(description) = The foo field.];
repeated string bar = 2 [(description) = The bar field.];
}
This is a new feature and I admit it is not adequately documented at the
moment.
This is a _really_ nice feature, very handy. I can see you put this
comment in the SVN logs, but it would be worth updating the main docs
soon so more people can find out about it.
2. Message Inheritance (vs. Extensions?)
Perhaps I just don't grok Extensions, but they seem more like a safety
feature than a re-usability mechanism.
Our feeling about case 1 is that the best way to accomplish it is to simply
embed an instance of the base message into your derived message. Sure,
we could add a whole lot of code generation which makes this look like
inheritance, but it does not seem worth the effort.
I'm fine with this - even though it's not real inheritance, it
fulfils the data structuring needs I have. I would have some
misgivings about being able to make a more complex inheritance scheme
as portable to as many languages as PB is. It is so easy to have
converters into JSON and simple data systems like that it would be a
shame to make that harder or impossible. PB keeps things simple but
scalable...
The most obvious problem with using inheritance in this case is that we
would need multiple inheritance even just to cover existing use cases. Many
people object to multiple inheritance for many reasons.
This is a powerful argument to not go there. I use C++ all the time
like the power and flexibility of the language, but oh my does it come
at a cost of complexity to handle things like this. If you only ever
intended to have PB connections between C++, Java, and other languages
of similar power, then it might make sense to consider inheritance,
but not with the wide range of language support that currently exists.
3. Typedefs
E.g., UUID=string, Timestamp=double, etc. Syntactic sugar is
always good.
Even many fully-featured programming languages -- e.g. Java -- don't provide
this.
True, but it doesn't mean it's a bad idea. I would suggest using the C
preprocessor to add #define for the typedefs you want. This way, it
doesn't interfere with PB, but allows you to add typedefs to your
data. I wouldn't mind seeing something like this in PB natively, but
it's not a major thing.
I suppose you could use that extend FieldOptions feature you
described to add meta-data describing the type, but it seems a bit of
overkill.
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.
What's wrong with defining your own UUID message? What would we gain from
having it built-in?
Agreed - this type is way too specialized to build into the language.
It may be common in some classes of application development, but
there's plenty of people like me who never use them. If PB added UUID,
then there would be calls for all kinds of application specific types
to be built in, such as date/time. In particular, since UUID is a
string, there seems little sense adding type handling for a formatted
string.
Jeff
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
