Sam,

On Thu, May 7, 2009 at 12:57 AM, Sam Johnston <samj@samj.net> wrote:
>
> I can see some value in running a knife down the middle... hence the talk
> about OCCI Core vs OCCI IaaS - where the former is a protocol ala HTTP
> (actually based on HTTP + Atom + magic fairy dust for search, caching, etc.)
> and the latter more an API that animates the resources with
> controllers/actuators, network and storage links, attributes, etc.

Admittedly I don't fully understand this but at face value I'd suggest
providing 'Core' first, whatever that is.

The ideal core protocol would contain no references to infrastructure, rather allow manipulation of resources (CRUD, linking, actuators) irrespective of what the resource was. It would thus be reusable for any resource (as Google have done for 16 different services and who knows how many different resource types already with GData).

The IaaS part would then define compute, storage and network resources and the various actions and linkages that make sense, leaving as much room as possible for innovation but ensuring the common parts are interoperable. In a year or two when people realise infrastructure is boring we'd just need to define resources for platform and software services rather than rewrite the protocol (almost certainly without backwards compatibility), or worse, create a new one.

>> > How would you recommend we deal with cases where XML is well supported
>> > but JSON is not well known?
>> >
>> > * .NET
>> > * Many 'enterprises'
<snip>

Personally I am in favour of JSON if it works and endorse Ben's
comment about not being tied down to whatever is in Visual Studio
today. I do think .NET will support JSON as a first class data format
in its official tools.

I've made it quite clear that I don't believe JSON will work (giving various technical reasons for same though there are various non-technical reasons too) and was hoping to see at least some of the outstanding questions addressed today now everyone's back to work.

"First class citizen" support of JSON is another of the more serious concerns - as it's executable(!?!?) JavaScript code it's obviously a first class citizen for JavaScript, but even for Java there are no less than 18 different projects listed at json.org in addition to the unsupported reference code. Enterprise movers and shakers will be pleased to know Python has just added the json module, only most of them are lucky to be using 2.5, let alone 2.6/3.0. For Microsoft's .NET languages though they're out of luck (except for some JSON code buried in ASP.NET AJAX) and it's the same story pretty much wherever you look - with the exception of PHP, native (let alone "first class citizen") support of JSON is very much a work in progress.

Most of the enterprise developers I know/work with wouldn't be allowed to touch most of this stuff without approval which (depending on the organisation) can be notoriously difficult to get - especially where legal has to approve the license. Native support is no problem though and I doubt there's a language in common use today that lacks native XML functionality. Ask again on an OCCI 2.0 timeframe.

If it is acceptable to use JSON in OCCI in order to stick to one
format for now (and learn from Sun's work) then great. I note that
GData supports JSON. I'd like to hear more from the .NET and
'enterprise' crowd though.

Has anyone (including Sun for that matter) implemented, let alone achieved interoperability with the Sun Cloud APIs? If not, what is there to learn that we haven't already gleaned from them (e.g. actuators)? I'm very happy to have Sun involved in this process (especially veterans like Tim) but they have stated they have no plans to implement the API I do think our requirements differ somewhat - Sun need an API for exposing the functionality of a specific public cloud service while we need one for exposing the [current and future] functionality of *every* service, public and private (including arbitrarily complex enterprise systems).

Also am I the only one to notice that JSON is not in fact a standard, rather the work of one (admittedly rather clever) Yahoo engineer? RFC 4627 is informational and "does not specify an Internet standard of any kind", having crept in under the guise of defining the application/json media type. That's fine for integration/convenience, but not for interop. Is it even possible (let alone sensible) to build a standard on top of a non-standard? Is there any precedent for SSO standards based on JSON? I still can't find any successful JSON-only APIs in the wild and this is one of my outstanding questions.

>> > If we 'went with JSON' then would it be plausible to have XML adaptors
>> > for non-JSON settings?
>>
>> Specifying the mapping is extra work. I suggest that YAGNI.
>
> I'll check it out.

Great!

Ok so I'm an idiot (perhaps we both are) - YAGNI is basically saying we don't need multiple formats despite there being various demands for same. It does seem likely that Sun don't need multiple formats for their service, but that's not to say we don't - the TXT format is an absolute requirement for use case E.2. "Simple scripting of cloud from Unix shell" for example

>> > Do you think Atom is a bad thing for our use cases?
>>
>> I'm not sure; I enumerated the things that I think would make Atom
>> attractive. For our use cases in the Sun API, it didn't seem like a
>> terribly good match.
>
> I definitely want us all to be on the same wavelength whatever we end up
> doing, but I also want to avoid closing doors unnecessarily (e.g. for
> enterprise/private cloud deployments). Sun Cloud API does look particularly
> good for public cloud (certainly better than the incumbent).

We do need to be careful about the difference between sticking to our
charter to the letter (public cloud first) and not closing doors.
It's a fine line.

Perhaps I'm going too far with genericity/extensibility but better too far than not far enough. This is more a side effect of accelerating change and not knowing what computing will look like next year, let alone for the entire useful lifetime of the standard!

Sam