On Tue, May 12, 2009 at 4:19 PM, Richard Davies < richard.davies@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