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

[Sam Johnston]

On Thu, May 7, 2009 at 1:17 AM, Tim Bray <Tim.Bray at sun.com> wrote:

> On May 6, 2009, at 1:44 PM, Alexis Richardson wrote:
>
> >   Failure is a possibility and for this reason
> > we have set ourselves a very tight schedule so that if we fail we can
> > fail fast and the interoperability community can learn from our
> > findings.
>
> FWIW, I've never seen a non-trivial language/protocol/API/standard/
> whatever designed in less than a year, elapsed.
>

True. I've been working on the problem for about a year now so I guess that
counts for something, plus we're trying to find the consensus of a large and
growing number of existing APIs so we're not starting from scratch. If this
trivia doesn't derail us I'm expecting to have a rough spec and reference
implementation demo in place in time for my Europe tour starting Monday
week.


> > Cool - can you or they contribute some use cases please?   We needs
> > dem use cases :-)
>
> Good point.  We have internal ones, had actually never thought of
> publishing them.  I'll see what I can do.
>

+1 that would be awesome - even if they're deidentified.


> >>  They do not rely on interoperable models,
> >> they rely on agreement on what bytes I send you and what bytes you
> >> send me and what the meanings of the fields are.  ....
> >
> > That sounds like a protocol mindset - consistent with your RFC comment
> > above.  But is OCCI a protocol?  Or is it an API?  What are your
> > thoughts here?
>
> I don't understand the difference, to be honest.
>
> The problem is that when you say API people expect object models and
> methods, and history should have taught us that those are very
> difficult to make portable across networks.  I confess to having a
> protocol mindset since I'm a Web guy.
>

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.

> More generally: What is the right way to make a cloud interface more
> > like a protocol?
>
> My opinion: Be RESTful, to the extent possible.
>

Agreed, no point redoing what HTTP's already done.


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


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


> > What about plain text - any view on that?
>
> Well, in our API, it turned out that the things we wanted to send back
> and forth were numbers, labels, lists and hashes.  Without exception.
> JSON had everything we needed built-in and nothing we didn't need.
>
> > 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).

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