[occi-wg] Is OCCI the HTTP of Cloud Computing?

[Alexis Richardson]

Sam,

On Thu, May 7, 2009 at 12:57 AM, Sam Johnston <samj at 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.




>> > How would you recommend we deal with cases where XML is well supported
>> > but JSON is not well known?
>> >
>> > * .NET
>> > * Many 'enterprises'
>>
>> Hmm... if you're in Java or Python or Ruby or of course JavaScript,
>> it's super-easy to consume and generate JSON.  If C# & friends are
>> behind in this respect I can't see it staying that way for very long,
>> my impression is that those guys are serious about keeping up with the
>> joneses.
>
> There's some ASP.NET stuff and some 3rd party stuff but it's certainly not
> burnt into the DNA like XML is.

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.

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.




>> > 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!



>> > 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.

alexis