Chuck Esterbrook wrote:
It's not hard to imagine they needed something faster and slimmer than
XML. Their motivations over XML are compelling:
No argument. There is no question that what they created is better than
XML for their purposes.
Regarding JSON and ASN, I would definitely lean towards them for their
self-description value, but obviously Protocol Buffers are going to be
faster and slimmer.
Faster. Unlikely. Take a look at the encoding:
http://code.google.com/apis/protocolbuffers/docs/encoding.html
*Lots* of bit munging. From my experience, ASN.1 is probably going to
be faster.
Comparisons against other binary protocols aren't shown. The only
comparison that they make is against XML.
Also, almost all the examples use C++ because it's the only language
that they use that has horrible serialization. Both Java and Python
serialize very nicely via introspection. Also, they only show it
against the most primitive DOM XML API, when most people use something
that operates at a much higher level nowadays (PullDOM, for example, on
Python).
Basically, I don't see the advantage over even something relatively
generic like ASN.1. And, I'm not suggesting ASN.1 is necessarily a
great solution because it suffers the same problem of not actually
associating the data with a label.
I found http://code.google.com/apis/protocolbuffers/docs/overview.html
rather informative. These are engineers solving the problems of their
company, not pariahs on an NIH binge. They have "48,162 different
message types defined in the Google code tree". It's not hard to
imagine that a custom solution was worthwhile for them to pursue.
Is it really NIH if you get a set of pros and cons that are (a)
different, (b) what you wanted and (c) heavily reused?
I don't think so,
You missed my point. Yes, it's better than *XML* because it's a
*binary* format.
The problem is that it doesn't seem to be any better than currently
existing *binary* formats and seems to have many limitations that even
something as generic as ASN.1 doesn't.
In addition, it loses the inline association between labeled delimiter
and delimited data. That's a large loss that many people won't think
about. Even associating a field with a one-byte label helps when
everything goes FUBAR. "Oh, hang on. Your format placed label "Q" as
the second item whereas we don't even have a label "Q" which means that
we've completely lost a field that we should have. Did we grab the
wrong IDL file? Or did we grab the wrong data file?"
This feels like a bunch of CS folks who couldn't be bothered to go
understand the tradeoffs of binary wire formats people have been using
for, oh, the last 20+ years.
-a
--
KPLUG-LPSG@kernel-panic.org
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
