Google Calendar and OpenSearch

google-atom-a9.gif

Seeing the new features in Google Calendar spurred me to dig a little deeper into Google’s Atom documentation, because the last time I checked, they hadn’t yet published any.

For a geek like me, their documentation was actually fun to read. Fun because it is a clear reflection of the thought and care they put into building a really robust API.

First, Google chose Atom as their base protocol. I say “base protocol” because I am beginning to think more and more of Atom as a framework and not the ends to a means. One can think of Atom in this way because it provides a really flexible set of semantics to describe virtually anything. For example, traditionally Atom has been associated with blogging almost exclusively, but in this case Google is using Atom not to manage blog posts, but to manage events. Six Apart on the other hand is using Atom to programatically control Photo Albums and TypeLists and is planning on using Atom as way to manage friends, categories, collections and virtually everything else. But I digress. The point is that Google uses Atom as a starting point and then extends it with its own set of semantics and data.

On a more obscure note, I really appreciated the section on “optimistic concurrency,” or in english: how Google prevents different programs from clobbering each other’s changes. Their approach underscores a mentality that I see a lot more in the Atom community then I ever saw in the SOAP world: a willingness to use HTTP for more than pure transport. HTTP comes with its own semantics for communicating status. SOAP chose to limit clients to a small subset of allowable status codes - primarily: success and failure. But Atom implementations tend to leverage the entire range of status messages as a means of communicating “ok, so you just request X, here is what happened.” This alleviates the need for the developer to encode these indicators in their response, and to use HTTP as it was designed. Who knew?

But perhaps the most interesting thing to me is how Google has integrated Amazon’s OpenSearch and Atom. OpenSearch is the perfect compliment to Atom because while Atom provides an excellent framework for creating, updating and deleting data, it doesn’t address the problem set of finding data quite as well. What OpenSearch provides to server is a simple way to accept and repond to search requests, and allows clients to discover from a search what search terms and query parameters the search engine accepts. From an automation perspective the means for a client to inspect a server’s capabilities, and syntax is huge because it allows a single piece of client software to talk to multiple and differing endpoints.

Google is doing an excellent job of establishing sound practices in regards to the Atom protocol, and in demonstrating to the market what all the bickering, flaming and debate about RSS and Atom was really all about. It has taken us too long to get here, but now that we can finally see the end of the road, it is a great relief, and I glad to see Google paving the way.

1 Comment

small quibble: please use OpenSearch with no space in the middle - it's the actual name, but more importantly allows search for OpenSearch easier ;-)

and I agree, OpenSearch suits this perfectly

Leave a comment

what will you say?


Recent Comments

  • small quibble: please use OpenSearch with no space in the middle - it's the actual name, but more importantly allows search for OpenSearch easier ;-) and I agree, OpenSearch suits this perfectly ...

Close