[occi-wg] Simple JSON rendering for OCCI

[Tim Bray]

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.

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.

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.

  -Tim
> Sysadmins conducting routine tasks with shell scripts (TXT)
> Task scheduling with cron (TXT)
> Automatic/autonomic task mechanisation, e.g. failover, recovery (TXT)
> Users wanting to learn the API/kick the tyres by hand (TXT)
> Exporting of [collections of] resources in arbitrary formats (OVF,  
> VMX, etc.)
> Documentation generation (ODF)
> Report generation (PDF)
> Diagramming (SVG)
> Accounting (CSV)
> Mapping to other protocols/implementations (EC2)
> End user web interface (HTML)
> End user RIA (XUL)
> etc.
> As for standards, one could point at XML and the subsequent need to  
> create XSLT ;)
>
> Sam
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg