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