> 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