Missed this... On Wed, May 13, 2009 at 10:44 AM, Alexis Richardson < alexis.richardson@gmail.com> wrote:
Sam,
On Wed, May 13, 2009 at 1:23 AM, Sam Johnston <samj@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