[occi-wg] Simple JSON rendering for OCCI

[Sam Johnston]

On Tue, May 12, 2009 at 6:11 PM, Chris Webb <chris.webb at elastichosts.com>wrote:

> Sam Johnston <samj at samj.net> writes:
>
> > Anyway Chris, weren't you now advocating a JSON-only solution?
>
> Personally, I remain a staunch advocate of whitespace separated KEY VALUE.
> To date, I have seen no technical justification for a more complex
> interface
> to something as conceptually trivial as an infrastructure cloud.
>

"Conceptually trivial" is not at all incompatible with "complex" at scale,
and as I've said before oversimplification will kill off a standard just as
efficiently as overcomplication.

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 which is fine for Twitter but useless for real applications
like OCCI on which enterprises will be looking to depend.

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 - remember that the
ElasticHosts API is at one extreme end of the spectrum and it's about
finding a balance - if we don't go far enough to be able to capture the use
cases then we are more likely to fail than if we go too far.

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

Once I've conceded that we won't pick the right format, I then have to try
> to advocate the 'least wrong' one. JSON carries much less baggage than
> Atom,
> requires much less code to parse, and will be easier to translate back and
> forth from something more sysadmin-friendly with a small standalone C
> utility, which I'll end up writing for our clients if we implement the OCCI
> API.
>

Ok I think I've seen more than enough now - so you're saying that in order
for the 1's and 0's on the wire passing between two computers to be pleasing
to the human eye you're prepared to write a "standalone C utility" but won't
under any circumstances accept XML? That's exactly what I referred to before
as "cutting off my nose to spite my face". Why not just forget all about
having a "pretty" protocol (which is a complete and utter waste of time for
all it matters) and run with something like ASN.1 or ProtocolBuffers then?

I'm just now starting to wonder whether I didn't wander into the wrong forum
and shouldn't be over at DMTF paying for the privilege of watching a gaggle
of vendors develop a standard that I might actually end up being able to
use...

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090513/8a5a5e77/attachment.html