Bob,

So the story behind OCCI is that I had planned to follow Google's example with GData 2.0 - it's essentially Atom Publishing Protocol (APP) extended for something like 16 different data types (everything from contacts to mails to videos) and it works nicely and has a bunch of clients already. Of course that ended in a religious war about the format-du-jour (XML vs JSON vs plain text) and we now actually have to do some real work (which is fine - the result should be better as a result). I wanted a draft by May (and still plan to deliver a final version by October) so now it's down to putting the current thinking on paper.

I've spent a few months reading up on the various options, studying great books like RESTful Web Services and examining many existing APIs. I'm now trying to get as close to HTTP as possible, essentially making the API an "overlay" that brings resources (e.g. vmx, vmdk, ovf files) to life. It will likely be detected via /.well-known/occi/ (ala robots.txt) and should be compatible with everything from basic HTTP to Subversion, Git and WebDAV (with HTTP PUT et al required for interop). Alternative representations (e.g. console screenshots, OVF files, etc.) and interfaces (e.g. to the state machine) are advertised by Link: headers and a category scheme lifted from Atom allows for flexible categorisation of an arbitrary number of resources (as well as questions like "show me the windows servers in the US without patch KB123456 applied).

We're also set to define a simple descriptor format following the footsteps of VMware's VMX (namespaced attribute value pairs - e.g "cpu.cores: 2") which will expose the usual IaaS functionality without the overhead of OVF/CIM (while retaining compatibility). This could prove particularly interesting for open source hypervisors.

All of this is subject to change - right now I'm working on making it mesh together and tacking difficult problems like enumeration, templates, etc.

Cheers,

Sam

On Sat, Aug 1, 2009 at 8:09 PM, Bob McWhirter <bmcwhirt@redhat.com> wrote:

Hiya Sam--

Yah, I saw that Rackspace also uses Link: type of headers, but I thus far haven't seen the need in what I'm doing. Perhaps next week I'll come to the realization as to why they're useful. :)

We're designing an API primarily, along with some implementations, and aim to have various language-binding clients for Ruby, Python, Java, etc.

I'm sure there's some overlap with everyone doing cloud stuff.

At this point, we're marching forward as fast as we can. I'll take a look at the OCCI stuff, though, and see if we can't find some common ground.

Thanks for the pointers,

-Bob

On Aug 1, 2009, at 11:05 AM, Sam Johnston wrote:

Bob,

Very interesting. Are you desigining a client or an API or both? A lot of this looks very similar to the current thinking around the OGF's Open Cloud Computing Interface (OCCI), right down to the discovery document and use of LINK elements (and HTTP Link: headers). More info at http://www.occi-wg.org/ but be warned that the documentation currently lags the discussions... it looks like there's a good opportunity for us to work together here (both client libraries like libcloud and standard interfaces like OCCI will be required).