[occi-wg] [Libcloud-list] API XML and Client Examples

[Sam Johnston]

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 at 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).
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090801/4cf9a8fe/attachment.html