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.
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