Alexis, On Fri, May 8, 2009 at 10:31 PM, Alexis Richardson < alexis.richardson@gmail.com> wrote:
OGF 25 is the presentation of a *draft*.
Anything that we have not agreed on, should not be presented at OGF 25 except clearly marked as 'draft and not agreed upon yet'. There is no point in presenting anything at OGF 25 that will not be supported by more than one implementation. OCCI is a plural venture. If in doubt, leave it out.
A "draft" is not an "implementable draft" if it's missing details like the core format. If we fail to deliver we'll be seen as just another talking shop releasing hot air into the cloud space by the many critics of (quite possibly premature) cloud standardisation efforts. That's not to say we should rush it but if there's a chance we can deliver on our promises then we *definitely* should. I am in favour of the notion of a 'primary format for interop.' at
this stage meaning prior to OGF 25. If requirements force us to go against Tim's advice to have one format, then we should assess them in a clear way, between OGF 25 and OGF 26. (I don't see how we can support multiple formats *now* and then easily simplify down to one format. On the other hand, it is quite easy to go from one format to many.)
I'd like to see consensus around the notion of one primary format for interop. for this draft stage and until we are forced to change that by clear user requirements.
Agreed, with the caveat that the suggestion was a "primary format for interop" AND alternative formats for convenience... you may be ok with insisting others use your $PREFERRED_FORMAT but I'm not. What I don't get is why, when the JSON junkies can have their cake, they insist on forcing the rest of us to eat it too (all in the name of simplicity no less, while actually creating complexity for those of us with anything but the most rudimentary of requirements).
Personally I have yet to see a showstopper concern against JSON, so I am still +1 on JSON over XML on grounds of simplicity and low costs of support. Sam, you say there are some but it would really help if you could lay them out in a list so that we can look at them one by one.
Let's see answers to the transformation and interoperability [with other standards] requirements first eh, then we can start talking about signatures, encryption, caching, extension, validation, etc. etc. etc. Sam On Fri, May 8, 2009 at 9:08 PM, Sam Johnston <samj@samj.net> wrote:
On 5/8/09, Benjamin Black <b@b3k.us> wrote:
On Fri, May 8, 2009 at 12:21 PM, Sam Johnston <samj@samj.net> wrote:
- Single-format: JSON
- Multi-format: JSON + XML + ?TXT
The list has also been fairly evenly split on whether multiple format support makes sense or not (independent of the choice of the single format).
The point is that there is significant support for multiple formats so multiple formats should be supported even if only as a convenience for disparate audiences (see Ben Black's comments on this topic).
I said the exact opposite: multiple formats creates complexity (either by requiring everyone support all formats or by allowing mutually incompatible yet compliant implementations) with little benefit.
I said that by NOT requiring people to implement anything but the primary format we can resolve your concerns. You have not demonstrated that there is little benefit and many of us had said that there is. The results of this straw poll demonstrate that clearly.
Trim the formats and you trim the audience and with it the potential for success. I definitely think we need to focus on one and give mechanical transforms as a convenience for the others though, which essentially addresses Ben's concerns about interoperability problems.
This approach does not address my concerns so much as amplify them.
How so? If there is one format for interoperability and others for convenience then we have the best of both worlds - the requisite transforms need not even be part of the spec, nor even developed by us.
I see three conclusions going forward:
1) Continue our specification in terms of the model (nouns, verbs, attributes, semantics of these, how these are linked together) with
both
JSON and XML renderings of this being explored on the wiki. We can decide later if we run with both or just JSON.
There is no "later"... I need to have my presentation for Prague submitted and a coherent format to discuss with SNIA by Wednesday. That's not to say the model is perfect but it doesn't have to be for us to move on - the wrinkles will iron themselves out with people cutting code between OGF 26 (in under 3 weeks) and OGF 27 (in under 6 months). There is huge value in raising awareness/familiarity amongst potential users as early as possible (release early, release often and all that). I'll be promoting OCCI in London and Paris in the coming weeks too, provided I still believe it's going to work.
Arbitrary deadlines based on having to give a presentation probably not the best way to produce quality solutions.
The deadline was decided pre-charter and appears in the launch release. It's inflexible.
There is still work here - e.g. verbs and attributes on networks have not
been specified, nor have we agreed fully the _model_ of how we link servers to storage and networks.
Thanks to Alexander Papaspyrou, Andy Edmonds: http://www.ogf.org/pipermail/occi-wg/2009-May/000461.html http://www.ogf.org/pipermail/occi-wg/2009-May/000444.html
The model is extremely simple - a compute resource can have zero or more network resources and zero or more storage resources. It gets hairy when you start considering that all three can be virtualised in which case there will be use cases which require going back to the physical devices, and that's why we need to support absolutely flexible linking between resources (something that Atom is particularly good at).
2) The JSON vs. XML debate is not just about angle-brackets vs.
curly-brackets.
I'm unconvinced that this has been demonstrated and still see it as 100% religion and bikeshed painting. Were we abusing XML then fair enough, but we're not - any simpler and it's plain text.
What you have convinced me of is that this is your clubhouse and the rest of us mere ornament so OCCI can appear to be a legitimate "consensus-based standards group". Not my cup of tea.
Ironically my insistence on XML is in order to AVOID forcing my opinion on others... I'd have thought that was pretty clear from each of my arguments.
I don't think anyone is in a position to say how cloud computing will evolve and suggesting that we know what tomorrow's datacenter will look like is extremely presumptuous, irrespective of previous accomplishments.
I note that my various serious/showstopper concerns about JSON in this context remain unanswered.
Sam on iPhone _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg