Google's Protocol Buffers announcement

Nick L., at Google, recently sent the Tucson JUG a link to a blog posting about Google's newly open-sourced Protocol Buffers:

http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html

"Interesting", I thought, "but why didn't you guys just use CORBA and get it over with?"

A snippet in the blog post seems to have anticipated that question:

"OK, I know what you're thinking: "Yet another IDL?" Yes, you could call it that. But, IDLs in general have earned a reputation for being hopelessly complicated."

Complexity sounds like a strawman here.....the major problem with IDLs is that they are built upon a shared definition, which requires all parties to update and recompile when the definition changes. And once you recompile, you've lost the ability of the system to handle the old message format (so versioning is a serious problem unless you plan for it from the beginning).

Of course, these problems are ameliorated when:
1) the IDL is for internal use only and,
2) you control both ends of the conversation,
as Google does...er...did up until now.

I also wonder why Google didn't just use an existing protocol like Hessian:

http://caucho.com/products/hessian.xtp

Perhaps a case of NIH syndrome? (http://en.wikipedia.org/wiki/NIH_syndrome)

Update - 7/20/2008:

Nick responded with these comments:

Google does tend to favor technology we invent ourselves ...[snip]... OTOH, some of the systems we've built ourselves have been blockbuster hits that enable much of what you know as "Google" today.

In response to your comment about backward compatibility, Protocol Buffers are actually explicitly designed so that you can add fields and whatnot and still be able to read in records stored in the old format.

I have to admit, the "WOW" factor on some of Google's software has inspired competition and innovation. So, the next time I'm looking for a binary wire protocol, I'll take a harder look at Protocol Buffers.