[occi-wg] Simple JSON rendering for OCCI

[Sam Johnston]

On Wed, May 13, 2009 at 1:56 AM, Tim Bray <Tim.Bray at sun.com> wrote:

> 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 <http://code.google.com/p/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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090513/8c7a532d/attachment.html