[occi-wg] Simple JSON rendering for OCCI

[Sam Johnston]

On Tue, May 12, 2009 at 4:19 PM, Richard Davies <
richard.davies at elastichosts.com> wrote:

I'm worried having a library of this size as a key dependency for OCCI when
> we could go with a much lighter meta-model (in either JSON or XML) and not
> require the library.
>

The existing client libraries are a convenience, not a "key dependency" -
you can use native XML parsers and only a few lines of code if you prefer
and the result will look very similar to its JSON counterpart. I assure you
there is no "much lighter meta-model", having gone through the process to
arrive where we are today. Each resource has:

   - Common attributes (ID, Title)
   - Resource specific attributes (CPU Speed, Memory)
   - Taxonomical information (Categories)
   - Generic Links (to other resources as well as descriptor files,
   screenshots, console, snapshots, etc.)

This maps perfectly to Atom and while I'm well aware of your concerns about
generic links I quickly start running into problems when trying to describe
screenshots, snapshots, consoles and other cruft we can't possibly hope to
predict. Aside from that there is virtually no difference outside of the
delimeters.

All existing cloud APIs (Amazon, Sun, GoGrid, ElasticHosts, etc.) have
> specified their APIs directly over HTTP rather than over a pre-existing
> meta
> model.
>

And Google? Microsoft? Salesforce? The fact they are all using AtomPub (two
of them strategically) is a very strong message as to its suitability in
heterogeneous cloud environments. Even VMware's vCloud is XML based so we
know what the top end of town wants/needs/will end up using.

What we need to find is the midpoint between the ElasticHosts API (plain
text) and DMTF APIs (heavyweight XML) that satisfies the needs of all cloud
infrastructure users... it's logical that this would end up being "just
enough XML" rather than "a little bit more than plain text" (JSON).

In fact it's worse than that... by going with JSON and ruling a line between
private and public cloud in the form of a separate API for each we would
essentially be forcing users to choose between the two. The only alternative
then is for public cloud providers to implement DMTF's standards in order to
reach the bigger fish as OCCI will be inadequate for their needs
(enterprises still [believe they] have needs for stuff like IPX/SPX that we
have no intention of specifying but should nonetheless allow for).

Should we really be pulling in a dependency which is this large when we have
> a clear choice not to?
>

XML support is natively present in any language worth using which is more
than can be said for the alternative.

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090512/1c679bb7/attachment.html