Randy Kahle and I are writing a series of articles on Resource Oriented Computing (ROC), which you can think of as REST principles applied to application software development. The first article of the series posted a couple of days ago on TheServerSide.com under the title
"A RESTful Core for Web-like Application Flexibility - Part 1"
Perhaps this title was somehow misleading since the article immediately engendered a passionate (and not always civil nor complementary) debate on various aspects of REST. Most of these were off-topic from the article. As a long time reader of TSS, I expected that something like this could happen. My attitude toward this is to encourage rational discussion, clarify misunderstood points, and ignore misbehavior. This is, BTW, an approach used successfully to deal with patients at mental hospitals.
Saturday, July 26, 2008
Friday, July 18, 2008
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:
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:
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.
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.
Subscribe to:
Posts (Atom)