[occi-wg] Voting result

Fri May 8 17:25:45 CDT 2009

Alexis,

On Fri, May 8, 2009 at 10:31 PM, Alexis Richardson <
alexis.richardson at 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 at samj.net> wrote:
> > On 5/8/09, Benjamin Black <b at b3k.us> wrote:
> >> On Fri, May 8, 2009 at 12:21 PM, Sam Johnston <samj at 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 at ogf.org
> > http://www.ogf.org/mailman/listinfo/occi-wg
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090509/28dab540/attachment.html 