[occi-wg] Simple JSON rendering for OCCI

[Sam Johnston]

Missed this...

On Wed, May 13, 2009 at 10:44 AM, Alexis Richardson <
alexis.richardson at gmail.com> wrote:

> Sam,
>
> On Wed, May 13, 2009 at 1:23 AM, Sam Johnston <samj at samj.net> wrote:
> >
> > Yes you can define a model and map it directly to a wire format like JSON
> (a
> > process that has been suggested a number of times already even today) but
> > when you need to modify it you need to go through the same process and
> risk
> > breaking existing code while you're at it. The result is both brittle and
> > inextensible
>
> Please can you spell out this argument so that I can understand it.
> When is a wire format "like" JSON, and why does modifying the format
> create a "brittle" system?
>

Parsing error? Try again s/JSON/POX/. The point is you create a monolithic
model, sign it off, and then blat it out as discrete operations. To make
changes you go back to your model, tweak it and blat it out again. Every
time you do a round trip you risk making all sorts of wheels fall off in all
sorts of ways - hence brittle.

If you have no need for extensibility (Twitter) that's fine. If you do you
want something like *eXtensible* Markup Language (XML) in which case you can
safely add what you like in full confidence that you will upset nobody. For
those parts that we want to interoperate we give a tight specification - for
everything else anything goes. IOW, your average request to ElasticHosts is
going to be skeletal while your average request to VMware (if they ever
implement it) will be relatively fat. Who cares?


> I have yet to see any convincing argument that JSON is worse for OCCI
> core than XML.
>

Yes you have, you just don't know it ;)


> Extensibility is the enemy of interoperability.  We should XML for
> Integration at the edge.  NOT for the interop core.
>

Rubbish - we need extensibility and there is no "edge" - if you get to the
"edge" of a protocol specified in this fashion you drop off the side. We can
have an infinite number of arbitrarily specified network parameters and so
long as we say that the "ip" and "gateway" fields are to be used for
interoperability we're fine - interop works side by side with extensibility.
Besides, as I explained before, interop is the exceptional use case -
integration is the rule.

If Microsoft decide to use "ms-ip" instead then they are not interoperable -
indeed if they don't specify "ip" the schemas will complain about
conformance too. For non-XML formats we don't have this luxury and have
either to point two possibly equally broken implementations at each other,
have a protocol analyzer in one hand and the spec in another, or both. I
know which I prefer.

> which is fine for Twitter but useless for real applications
> > like OCCI on which enterprises will be looking to depend.
>
> Meaning what exactly?
>
> "Enterprise" is a politically loaded term with no fixed denotation.
> See here just one example of "enterprise" being interpreted in a
> manner convenient to the author:
>
> http://www.zhen.org/zen20/2009/05/13/google-lost-grip-on-enterprise-reality/
>

Where you see me say "enterprise" you can substitute "business with a 5 or 6
figure headcount, usually from this list<http://en.wikipedia.org/wiki/CAC_40>
".

Oh, and VMware bashes Google, claims enterprise wants private cloud. No they
don't <http://samj.net/2009/05/bragging-rights-valeos-30000-google.html>.
Film at 11.


> >> However, because optional formats will (by definition) not be universal
> >> and
> >> hence not something that portable apps can rely on, and given that I
> (like
> >> you) am in the minority with this view, realistically I have to accept
> >> that
> >> we'll end up specifying mandatory data format(s) which wrap(s) the data
> in
> >> pointless fluff.
> >
> > Your "pointless fluff" is anothers' absolute requirement
>
> Requirement for integration or for interop.?  A requirement for
> integration, may indeed be pointless for interop.  It may even be
> fluffy :-)
>

Most of our use cases are for integration, not interop. That makes sense
when you think about it - I want my systems to work well together and
couldn't care less about moving them (except as a loaded shotgun when it
comes to contract negotiations).

> Here's the alternatives ordered by decreasing complexity... even vCloud is
> > significantly less complicated on the wire than WS-* so far as I can
> tell:
> >
> > WS-* (SOAP/XML-RPC)
> > DMTF (vCloud/OVF)
> > OCCI-XML <- sweet spot IMO
> > OCCI-JSON
> > TXT
>
> Good diagram.  I agree with the order but not the sweet spot.
>
> So I think we are all gradually getting closer to being able to debate
> specific issues without other issues getting in the way.  This is
> great progress.
>

Sure, as soon as people realise that what might work for them won't
necessarily work for everyone we can move on.

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