Protocol Buffers: No Big Deal
July 11th, 2008 | Published in distributed systems, HTTP, RPC, services | 7 Comments | Bookmark on Pinboard.in
I’ve gotten a few emails asking me to blog my opinion of Google’s Protocol Buffers. Well, I guess I pretty much share Stefan’s opinion. I certainly don’t see this stuff providing anything tremendously innovative, so as with Cisco Etch, it seems to me to be just another case of NIH.
Ted Neward already wrote a pretty thorough analysis — it’s almost 0.85 Yegges in length! — so I’ll just refer you to him. There are at least two important points he made that bear repeating, though:
Which, by the way, brings up another problem, the same one that plagues CORBA, COM/DCOM, WSDL-based services, and anything that relies on a shared definition file that is used for code-generation purposes, what I often call The Myth of the One True Schema.
Indeed. Usually when one points this out, those who disagree with you come back with, “Oh, that doesn’t matter — you can just send whatever data you want as a string or as an array of bytes!” Having been forced to do just that numerous times back in my CORBA days, I know that’s not a good answer. You have a bunch of distributed infrastructure trying to enforce your One True Schema Type System, yet you go the extra mile to tunnel other types that don’t fit that schema through it all, and the extra layers can end up being especially complicated and slow.
The second point I’ll quote from Ted says it all:
Don’t lose sight of the technical advantages or disadvantages of each of those solutions just because something has the Google name on it.
Most excellent advice.
There’s one last thing I’ll quote. This one’s not from Ted, but directly from the Protocol Buffers documentation:
For example, you might implement an
RpcChannelwhich serializes the message and sends it to a server via HTTP.
Sigh.
[Update: more opinions — and some questions — in my next post.]
July 12th, 2008 at 12:20 am (#)
I still stick with the
being the deal killer ….
July 12th, 2008 at 12:59 am (#)
I would argue that almost anybody who decides to try to use this at internet-scale is making a mistake.
It’s designed to be able to exchange lots of data at wirespeed.
July 12th, 2008 at 6:13 pm (#)
It’s beginning to look as if Google is becoming something of a sourceforge even for their own external releases.
Last month it was App Engine with YAML is a human friendly data serialization, this week it’s lets go binary with Protocol Buffers..
From the outside it looks as if Google is suffering from a bit of “cat herding syndrome”..
Maybe this blog post from a couple weeks ago wasn’t so far off
Tony
July 14th, 2008 at 10:21 am (#)
Google is the new Microsoft — inventing something new for a problem that is known for decades and already has several widely used, well known industry standard solutions like ASN.1. The saddest of all is that the google guy announcing the opening of the PB source doesn’t even know about ASN.1:
“Sorry, I personally am not very familiar with ASN.1 DER. A brief look at some documentation suggests to me that it is more complicated than Protocol Buffers, which can be good or bad depending on whether you need that complication.”
July 14th, 2008 at 12:57 pm (#)
[…] call. Among posts on this topic were such highly respectable people like Ted Neward, Stefan Tilkov, Steve Vinosky here and here or Dare Obasanjo. Unfortunately those “big shooters” failed short with clean […]
July 16th, 2008 at 5:25 pm (#)
[…] Vinoski – Protocol Buffers: No Big Deal, Protocol Buffers: Leaky […]
July 31st, 2008 at 2:56 pm (#)
[…] much quite. But, as with anything touched by todays Midas, Google’s Protocol buffers stirred a bigger debate on the merits of […]