"Protocol Buffers" for Tango & Phobos ??

[Brian Price]

== Quote from Leandro Lucarella (llucax at gmail.com)'s article
> Brian Price, el  1 de septiembre a las 14:31 me escribiste:
> > 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.
> Different problems has differents solutions. What you say is really nice
> and have sense when *latency* and other performance issues are not a problem
> to you (it's obviously a problem for Google and for a lot of other people,
> like me, I was doing a little "framework", similar to Google's PB at work,
> just before they release it =).
> When you deal with (almost) realtime systems, you can't pay the price for
> human readability, extra parsing time, extra abstraction and extra bytes
> thrown throgh the wire. You just can't.
> You don't even care about portability (this kind of things usually run in
> a very controlled environment).
> I just wanted to clarify this.

In a (near) realtime embedded system with a high wire cost (cellphone, smart
meters, etc) I'd have to agree with you.  However, my initial impression was that
this was being proposed/offered as a general purpose object streaming system.

Multicore/hyperthreaded processors with multiple levels of caching have a huge
latency (comparitively) between core and wire.  Even in a high demand system
there's generally plenty of cpu cycles left over to do quite a bit of extra
parsing and data massaging (compression).  A compressed text message (XML or JSON
format) is very competitive in size with binary format (depending of course on the
actual makeup of the data payload).  I expect that in a few years the embedded
systems will be sporting processors with similar capabilities to today's desktops
and servers.  At that time, it may be worthwhile re-evaluating the decision to go
with a 'brittle' binary format in new designs.

On a personal note, some of my friends are laughing at me over this - ten or
twelve years ago I was vehemently against the idea of using human readable data
formats for transmission - for the same reasons you give above.  Of course my
cellphone today probably has nearly the power of my desktop back then.

Sorry for any misunderstanding,
Brian