[occi-wg] Voting result

Sat May 9 06:47:50 CDT 2009

Sam,

Very quickly.. as I have to rush.

On Fri, May 8, 2009 at 8:21 PM, Sam Johnston <samj at samj.net> wrote:
>
> This isn't even a loose consensus...

Correct.  We don't have consensus and we need to converge not diverge.
 To do so I am splitting the debate into sections:

* Model
* Interoperability
* Metamodel
* Integration

.... IN THAT ORDER PLEASE ....

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

JSON vs XML for interop.

People have started replying to this.  We need to take the 'data
format and interop' question into its own thread, and separate it from
integration.

---> separate thread

> We all agree that anything but the most basic specification of compute,
> storage and network resources is out of scope, but we then give no option
> but to have clients talk multiple APIs developed by multiple SSO's (almost
> certainly with completely different formats and structures). Am I the only
> one who sees a complete and utter clusterf--k in the making (think WS-*
> redux JSON edition)?

I'm afraid you have convinced me that multiple formats for interop
will lead us to to WS-*.

More on this later.

>> I don't consider this as a vote for a decision, but do think it has drawn
>> out a lot of opinions and shown the lay of the land more clearly - in the
>> light of the votes, the only two viable options are:
>
> 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). It's worth mentioning that I
> well appreciate the advantages of JSON but this is about choosing the right
> tool for the job - XML may be a sledgehammer but everyone's got one and you
> can't drive a nail with a screwdriver.

JSON vs XML for interop ---> separate thread.

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

IMO - No.

Support for something does not make it necessary for interop.
Multiple formats is an integration issue.  More on this later.

> Trim the
> formats and you trim the audience and with it the potential for success.

IMO not true.  The opposite is true for interop.  Mess up interop and
you have no success at all.  We don't want an OCCI-Interop group to
have to be formed later, in order to make all the variances between
formats go away.

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

One for INTEROP.

Many for INTEGRATION.

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

Feel free to present what we have agreed on.  The rest is w.i.p. and
subject to change.

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

Model -- to the model thread please.

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

To the JSON vs XML thread.

>> Amongst the XML supporters, I have seen little opposition to a GData/Atom
>> meta-model around the nouns/verbs/attributes. [Tim Bray, who co-chaired
>> the
>> IETF Atom working group, felt it was the wrong choice, but then he doesn't
>> support using XML at all in this context]
>
> I'm less and less convinced that we're trying to solve the same problem
> here... the public cloud interfaces are extremely light (too light in
> places) but functional while the private cloud stuff is overkill. There is
> middle ground and we need to find it if hybrid clouds are to be a reality.

Thanks for pointing us at Tim's post:
http://www.tbray.org/ongoing/When/200x/2009/03/16/Sun-Cloud  .. I
think he also aims at the middle ground "Lightweight lockin-free
data-center virtualization might be bigger, I think."

>> Do the 10 JSON supporters agree with this, or have I misjudged it and
>> there
>> is actually strong support for GData-JSON?
>
> By GData-JSON you of course mean a generic XML to JSON transformation which
> results in functional but ugly JSON. I'm unconvinced that a "pretty"
> protocol is a requirement provided it is still accessible/approachable -
> this works for Google so it will work for us, and it's trivial while your
> proposed alternative is very far from it.

Interop. is the priority.  Syntax and sugar --> integration.

> That said, work on Atom to JSON has already been done and an
> "application/atom+json" RFC would be hugely beneficial for many audiences.
> I'd suggest JSON be a convenience primarly for web developers and that a
> generic XML to JSON transform be used while an Atom to JSON transform is
> developed (that's something I'd happily to contribute to separately).

TBD.

>> Myself and Chris would be happy to lead developing the JSON rendering it
>> its
>> own right if people agree with my statements above and hence that it does
>> need independent development (from the same set of nouns/verb/attributes
>> and
>> semantics).
>
> That's all well and good but anyone can write a "rendering" - it's the
> "renderer" that's hard work. If you and Chris are volunteering to get us to
> the point we are already with XML, by Wednesday, then we've got something to
> talk about.

Richard, Chris, do what you feel is needed .... over to you ;-)

> The point is that there are many different audiences to satisfy and we can
> trivially satisfy them all, quickly, if we stick with lightweight XML. Move
> to JSON and there's serious doubt as to whether we'll even be able to
> deliver on our charter (e.g. playing nice with others).

This is to be discussed.

> Something you haven't covered in your summary is the strong consensus to
> keep the model and protocol separate. That's something that I for one would
> like to see more of going forward and I specifically don't want to see the
> model spilling over into the protocol if it will limit its potential
> application and complicate/specialise mechanical transformation.

Not sure what you mean - I think Richard is keeping them very
separate, as is the Sun API approach.  IMO, this actually should be
part of the metamodel discussion: CRUD/HTTP vs REST/HTTP approaches,
etc.

alexis

> Sam
>
>> Cheers,
>>
>> Richard.
>>
>> ==========================================
>>
>> JSON: 10
>> - Alexis Richardson
>> http://www.ogf.org/pipermail/occi-wg/2009-May/000405.html
>> - Andy Edmonds http://www.ogf.org/pipermail/occi-wg/2009-May/000420.html
>> - Ben Black http://www.ogf.org/pipermail/occi-wg/2009-May/000395.html
>> - Krishna Sankar http://www.ogf.org/pipermail/occi-wg/2009-May/000455.html
>> - Mark Masterson http://www.ogf.org/pipermail/occi-wg/2009-May/000440.html
>> - Michael Richardson (private mail to me)
>> - Randy Bias? (JSON listed first at
>> http://wiki.gogrid.com/wiki/index.php/API:Anatomy_of_a_GoGrid_API_Call)
>> - Richard Davies http://www.ogf.org/pipermail/occi-wg/2009-May/000409.html
>> (split EH vote)
>> - Tino Vazquez? http://www.ogf.org/pipermail/occi-wg/2009-May/000411.html
>> - Tim Bray http://www.ogf.org/pipermail/occi-wg/2009-May/000418.html
>>
>> XML: 5
>> - Chuck W http://www.ogf.org/pipermail/occi-wg/2009-May/000448.html
>> - Gary Mazz http://www.ogf.org/pipermail/occi-wg/2009-May/000470.html
>> - Kristoffer Sheather
>> http://www.ogf.org/pipermail/occi-wg/2009-May/000430.html
>> - Sam Johnston http://www.ogf.org/pipermail/occi-wg/2009-May/000381.html
>> - William Vambenepe
>> http://www.ogf.org/pipermail/occi-wg/2009-May/000396.html
>>
>> TXT: 2
>> - Andre Merzky http://www.ogf.org/pipermail/occi-wg/2009-May/000447.html
>> - Chris Webb http://www.ogf.org/pipermail/occi-wg/2009-May/000409.html
>> (split EH vote)
>>
>> Single: 3
>> - Benjamin Black http://www.ogf.org/pipermail/occi-wg/2009-May/000457.html
>> - Tim Bray http://www.ogf.org/pipermail/occi-wg/2009-May/000418.html
>> - Richard Davies (revised in light of Tim Bray's comments)
>>
>> Multi: 3
>> - Gary Mazz http://www.ogf.org/pipermail/occi-wg/2009-May/000458.html
>> - Marc-Elian Begin
>> http://www.ogf.org/pipermail/occi-wg/2009-May/000439.html
>> - Sam Johnston http://www.ogf.org/pipermail/occi-wg/2009-May/000445.html
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/occi-wg
>
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
>