[occi-wg] Voting result

Fri May 8 15:31:39 CDT 2009

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.

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.

----

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.

alexis

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
>