[occi-wg] Voting result

[Sam Johnston]

On Fri, May 8, 2009 at 10:58 PM, Tim Bray <Tim.Bray at sun.com> wrote:

> On May 8, 2009, at 12:21 PM, Sam Johnston wrote:
>
>  I'm still far from convinced that JSON meets the minimum requirements to
>> be in the running in the first place and nobody has addressed this point
>> except to tell me to go back to square one and formally define them. Even
>> the JSON junkies concede that while "XML documents can contain any
>> imaginable data type", "JSON does not have a <[CDATA[]]> feature" so unless
>> we want to contribute to the creation of a circus of cloud standards rather
>> than provide the coherence of a loose framework on which to build, this
>> point at the very least needs to be addressed.
>>
>
> What on earth does CDATA have to do with anything? JSON can carry arbitrary
> textual payloads without any extra effort.    Oh, here's a dirty secret:
> both XML and JSON are lousy "wrapper" formats.  If you have different kinds
> of things, you're usually better off letting them stand alone and link back
> and forth; that hypertext thing.
>

Right so say I want to create a new resource, or move it from one service to
another, or manipulate its parameters, or any one of an infinite number of
other potential operations - and say this resource is an existing virtual
machine in a binary format (e.g. OVA) or an XML representation of a complex
storage subsystem or a flat text network device config or... you get the
point. It is *far* simpler for me to associate/embed the resource with its
descriptor directly than to have a two phase process of uploading it and
then feeding a URL to another call. I do expect this to be an exception
rather than the rule, but it's critical in that if you can't (easily) get
resources into and out of the system then we have failed.

There's certainly going to be other standards around networking and security
and storage and... so why would we not give them a sensible home when we
just as easily can?

As an aside I wonder how many times there were conversations like this
previously (where working groups had the blinkers on with the usual "not in
the charter" cop out) and how significant a contributor this inability to
work together was to the WS-* train wreck...

I have not been to the mat with the OCCI use cases so I'm not going to argue
> that they contain things that can't be done in JSON.  We didn't find any in
> our use-cases, but that may not be relevant here.
>

I think it's mostly about finding a balance between simple public cloud
interfaces and overcomplicated virtualisation^Wprivate cloud interfaces...
it would be a real shame if public clouds used OCCI and virtualisation
setups used OVF-NG or whatever they're calling it. I'm envisaging OCCI being
useful for a single workstation through (thanks to
search/categories/tags/etc.) an entire organisation... I know that Amazon's
EC2 API starts to choke when you have serious numbers of resources and I'll
bet others have similar scalability problems. Tangential perhaps, but it
helps to understand what we're trying to achieve... I have a negative
interest in churning out something like Amazon's EC2 API or, at the other
end of the scale, something like OVF. I honestly believe that Atom/XML is
the happy medium and it's worth reminding you that I have no agenda
whatsoever outside of delivering the best interface possible.


> The disconnect here that's fascinating, looking in from outside, is between
> the people who feel that having multiple message formats is a problem and
> those who feel it's essential.
>

True. People have asked (and will continue to ask) for support of the format
du jour... which is in part why I was positioning the OCCI core protocol as
something akin to HTTP; it doesn't care what it carries, but it lacks the
minimal of structure that we require.

Remember also that Google are already using this in production for a myriad
resources on a truly massive scale (and have already ironed out the bugs in
2.0) - the same cannot be said of the alternatives and dropping by their
front door on the way could prove hugely beneficial. It will also allow us
to reconvene when infrastructure gets boring (probably a year or two from
now) and add new resources for e.g. platforms and applications without
having to rewrite the entire protocol or start from scratch.


>
>  Definitely, the arguments have been enlightening but there are still some
>> big knowledge gaps. Mechanical transformations are another point that the
>> JSON crowd have been totally silent about, likely because there is no
>> solution that doesn't involve delving into the details of programming
>> (something which is strictly out of bounds).
>>
>
> One of the reasons that us single-data-format people feel that way is that
> it moves the transformation problem out of scope.  Less work is good.  I
> guarantee that the in-memory object model of our cloud infrastructure app
> doesn't look anything like either XML, or the JSON in the Sun REST API, or
> any other conceivable protocol format.  An implementor is going to have to
> transform between protocol and application semantics anyhow; I just don't
> want to have to do it more than once.  -T
>

This sounds a lot like an externalisation: those in the best position to
solve a problem damn well should, especially when it would be more
expensive/impossible for others to do so. For JSON you have no choice but to
roll your own translator - one for each language/platform you need
translations done on. Conversely, for XML we can write the transform once
and users (including others like the large and growing Atom community) can
deploy it on any platform they like (even browsers) as well as contributing
their own transforms.

It's almost too easy (as evidenced by what I've managed to achieve in a week
or two on my own and with no prior XSLT experience), though maybe that's
another problem for those who'd prefer it be harder.

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