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.
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.
[Update: more opinions — and some questions — in my next post.]