"Protocol Buffers" for Tango & Phobos ??

[Brian Price]

== Quote from Nick B (nick.barbalich at gmail.com)'s article
> Hi
> I came across this the other day, and no one has mentioned this, on this
> news group before, I thought I would bring the subject to the
> communities attention, so to speak.
> Google has very recently, open sourced "Protocol Buffers".
> What is it you ask ?  In a couple of lines it is a language-neutral,
> platform-neutral, extensible way of serializing structured data for use
> in communications protocols, data storage, and more.
> Think XML, but smaller, faster, and simpler.
> Why not just use XML ?
> Protocol buffers have many advantages over XML for serializing
> structured data.  Protocol buffers:
> * are simpler
> * are 3 to 10 times smaller
> * are 20 to 100 times faster
> * are less ambiguous
> * generate data access classes that are easier to use programmatically.
> PB supports Java, Python,and C++ currently.
> A more detailed overview can be found here:
> http://code.google.com/apis/protocolbuffers/docs/overview.html
> and the FAQ here:
> http://code.google.com/apis/protocolbuffers/docs/faq.html
> See the answer to the question "Can I add support for a new language to
> protocol buffers?" inside the FAQ.
> Some Tips and comments can be found here:
> http://zunger.livejournal.com/164024.html
> My questions.
> Does the D community see this of interest ?
> Is this something they might use ?
> Do they see value in it being added to the respective
> Tango or Phobos frameworks ?
> any other comments ?
> cheers
> Nick B.

Hate to say it but this is yet another case of reinventing the wheel.  The worst
thing about this throwback to the early 90s is its inherent violation of DRY.
This package intermingles and confuses three separate issues, treating them as a
monolithic whole, namely: serialization, marshalling, and versioning.

Binary solutions such as this, while more efficient byte-wise, run into
portability problems especially with floating point values.  They also lose the
human readability of the data (sans the use of special tools).  Often the use of a
binary solution is a case of premature optimization and indicates bad design at a
higher level.  The marshalling strategy should be 'pluggable' so that one can use
an easier to debug, human readable, data format during development.

Versioning problems can be (and have been) addressed in a number of ways over the
years, the simplest and imo often the best, is to sidestep the problem by
serializing a map of the data rather than just the raw data.  That is, each value
has associated metadata indicating its field name (a key-value mapping iow).

If XML is too heavy a hammer, JSON (with or without embedded metadata) is a good
alternative with quite a bit of industry support.  In fact, the use of JSON
encoding with embedded metadata gives you a lightweight solution that works with
nearly every language in present use.  Even better, any language with good
reflection support (such as Java) allows an implementation that does not violate DRY.

This "Protocol Buffers" solution is a dinosaur, a throwback, yet another wheel
when we need ground effects or anti-gravity.

My 2c,
Brian