On May 12, 2009, at 9:09 AM, Sam Johnston wrote:

You have argued on many occasions that mechanical transformation of the OCCI protocol data format is a key requirement. I've never understood why, and I've never engaged in a protocol design where this was an issue. Could you expand on why this matters? -Tim

True, but I've also cited on many occasions use cases that rely on specific formats. Here's a dozen that come to mind and would otherwise have to be manually coded by each implementor:

Ah, I get it. I 100% agree that this is a problem. We thought about this a lot in the Sun-API design process. But ended up in a different place. We were pretty convinced that REST was the right basis for the API. It just can't be beat in terms of integration flexibility and network-friendliness. The problem is, a lot of programmers and sysadmins don't want to talk directly to a REST interface.

If the REST interface spits out a trivial format (eg KEY VALUE) then it's easily consumed by programmers, cron jobs, failover scripts, users at the command line, tools like cush, etc. If it spits out anything more complex (XML, JSON) it's essentially useless for these use cases. Moral: support for multiple formats in the server makes the life of the clients much easier, especially since there are few server implementations to very many clients. Content negotiation works and exists with good reason.

So, what we did was write simple wrapper libraries in Java, Ruby, and Python (someone's working on PHP too) that give you VM, PrivateNetwork, Cluster, and so on classes wrapped around the REST/JSON calls. Plus, a little command-line tool (in python, so it should run on anything) so you can say

cloud_command --list --cluster Database
cloud_command --attach --privateNetwork PN1 --vm Database/3X03

We'll be publishing those under an Apache2 license Real Soon Now.

That all sounds great for a packaged product (in which case the format over the wire could be completely obfuscated for all the user could care) but ideally APIs should be directly approachable by all users without the need for tooling.

I'm unconvinced that auto-generation of different version of your protocols messages will be that much help to sysadmins and script-writers and so on, but you're closer to the use-cases than I am.

It's hard to imagine all the possible use cases for OCCI but the ones we have already go somewhat further than what you've needed for the Sun Cloud APIs. There will certainly need to be extensible support for things like billing, monitoring, SLAs, etc. for example as well as good support for "supporting" (e.g. SNIA) as well as "competing" (e.g. OVF) standards. This is all handled seamlessly and safely with XML[NS] and can be validated as much as required.

I could not be more convinced that JSON is not [yet] up to the task for OCCI (even if spot on for Sun Cloud APIs) but there's only so many ways I can say it before giving up and wandering off; I'm not going to invest time in a project I no longer believe in and/or have a use for but I don't want to keep the rest of you from reaching consensus any longer than I already have.

Sam