[occi-wg] Deadline for consensus [rant]

Tue May 26 19:23:23 CDT 2009

Gary,

We can make OCCI transport and representation agnostic, which was suggested
> early on. That requires a logical model definition and selection of an
> implementation (a semantic model).  The OCCI ended up with that exact
> structure for the specification. In fact, though the hard work of Andy
> Edmonds, we even have a start for defacto representation language of the
> OCCI logical model in XSD.
>

You're right - churning out XSDs for complex structures can be hard work and
Andy's obviously been busy. Fortunately with the latest iteration it's not
necessary - each resource is a minimalist OCCI key-value format (be that
text, json or xml) accessible over raw HTML with all metadata available via
the HTTP headers. We really can't get closer to raw HTTP than that, the only
exception being collections which do require some structure in the form of
multipart HTTP messages or a lightweight Atom-style meta-model.

> If, we re-evaluate transport and representation agnostic strategy for OCCI,
> we can pick a "first implementation" with the knowledge we will "need" other
> implementations in the near future. IMO, I do not believe for one second we
> can get away with one implementation, not with the recent trend in protocol
> adoption. Adopting this strategy does not exclude providing bridges and
> gateways, more traditional works,  to bridge technology gaps between OCCI
> and foreign systems, in fact agnostic strategy may produce a more valuable
> technology.
>

Agnostic strategy is more of an academic approach - we need something
practical and implementable. Fortunately by offloading the meta-model
requirements in order to reach flat key-value simplicity we barely need to
specify anything (see the wiki for the three examples).

> The bottom line; is PICK ONE implementation, if we are not happy with it,
> or the protocol fashion critics frown on the OCCI  for "not playing in top
> of mind", we can always give it a face lift. Pick one, its a interchange and
> management system.
>

Again, with key-value we can have our cake and eat it - rendering all three
proposed formats is trivial for implementors (read: ~2 LOC per format).
Parsing is a different story but we have a simple and elegant solution by
way of form submissions (it's just key-value remember) which as a bonus
supports embedding files. Virtually all HTTP user agents support form
submission which translates to zero code required for interacting with OCCI.

> IMO, there is only ONE big issue that affects the decision on which way to
> go:  human usability/readability in native form. If is is an ABSOLUTE
> requirement, go with atom. If not, some XML representation.  Either way you
> WILL be representing the OCCI logical model.
> One more issue in my rant, on the issue of human usability/readability,
> once you include links, the protocol is no longer "easily interpretable". An
> example is the Widows registry: its human readable, but try to read and find
> all the linked GUIDs. Its nearly impossible to find them, human readable or
> not. Reading the OCCI will have the same issues as reading the Windows
> registry.  Human usability/readability is a pipe dream, at least without
> putting a lot of work into publishing rules, which complicates
> implementations.
>

If we want to merge the human and programmable web then our default format
should be (simple) [X]HTML. Remember machines can read this too and indeed
the sample Google Maps style API developed in "RESTful Web Services" (pp126)
uses XHTML for an interface that is friendly to both humans and machines. In
the context of OCCI your list of networks might end up looking something
like this:

<ul class="network">
  <li><a href="/abc">Internet</a></li>
  <li><a href="/xyz">Private Network</a></li>
</ul>

This still feels a bit funky for me, though it's pretty much the same amount
of effort to write xpath queries for this as what it is for POX and users
being able to "browse" your API is hugely advantageous for approachability.

I'm guessing that implementors will differentiate on the number/type of
formats they support... at a minimum being the ones we specify with the
"must" requirement level.

Sam

Sam Johnston wrote:
>
>> On Tue, May 26, 2009 at 4:23 PM, Roger Menday <
>> roger.menday at uk.fujitsu.com <mailto:roger.menday at uk.fujitsu.com>> wrote:
>>
>>
>>    Hi Sam,
>>    not to undervalue your hard work, but in my opinion I don't think
>>    we will be able to make a decision this week. We don't have all
>>    the time in the world, but I don't fancy rushing a decision on
>>    this one.
>>
>> If you're right and we can't make a decision this week (bearing in mind
>> that all the information we need to make it is already on the table) then I
>> fear we'll not be able to make a decision at all. It certainly wouldn't be
>> the first working group to lose inertia after getting caught up in a
>> religious debate and it won't be the last, but we need to draw the line
>> somewhere and get on with the job. Public perception aside, it's important
>> that we don't miss the only opportunity we have to gather information from
>> an OGF event rather than wasting even more of everyone's time.
>>
>> What more do you need for us to get out of this rut because I'm beginning
>> to lose faith... what started as something I was proud to be involved in is
>> fast becoming an embarassment.
>>
>> Sam
>>
>>
>>     All,
>>>
>>>    As you know our already extended deadline for the formats
>>>    discussion passed on Friday. Thijs is now in the unfortunate
>>>    position of having to explain why we will miss our first
>>>    self-assigned deliverable deadline (an implementable draft) on
>>>    Thursday and I know well how it feels to have to stand in front
>>>    of an audience with nothing to say, having done so twice last
>>>    week (it's only with a big "personal vision only" disclaimer that
>>>    I was able to say anything at the Cloud Computing Expos).
>>>
>>>    Iff we can come to consensus about the format today (or at the
>>>    very latest tomorrow) then we need not watch another deadline
>>>    sail by and in doing so risk being declared a failure
>>>    prematurely. Indeed if we can't achieve even a loose consensus
>>>    after all the discussion then I may well be the first to say so -
>>>    my time (and travel!) budget for OCCI has already been well
>>>    exceeded and the irrelevant RF vs RAND discussion has tested
>>>    what's left of my patience. Please focus on the task at hand and
>>>    if you have any specific issues about the latest proposal then
>>>    raise them sooner rather than later - I've put considerable
>>>    effort into optimising Atom out for the most common use case
>>>    (individual resources) over the weekend and by shifting metadata
>>>    to HTTP headers the resulting descriptor format is far simpler
>>>    than even I would have thought possible - see APIDesign
>>>    <
>>> http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/APIDesign
>>> >
>>>    for examples.
>>>
>>>    On the subject of rolling our own protocol from scratch, I for
>>>    one am dismissing the suggestion for reasons previously
>>>    explained. I don't think this group has (nor needs) what it takes
>>>    to implement an Internet protocol from the ground up and any
>>>    attempt to do so would be fraught with danger, not to mention
>>>    completely unnecessary given the corpus of work done by others at
>>>    the IETF (who _are_ geared up for such tasks).
>>>
>>>    Thanks,
>>>
>>>    Sam
>>>
>>>    _______________________________________________
>>>    occi-wg mailing list
>>>    occi-wg at ogf.org <mailto:occi-wg at ogf.org>
>>>    http://www.ogf.org/mailman/listinfo/occi-wg
>>>
>>
>>    Roger Menday (PhD)
>>    <roger.menday at uk.fujitsu.com <mailto:roger.menday at uk.fujitsu.com>>
>>
>>    Senior Researcher, Fujitsu Laboratories of Europe Limited
>>    Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE, U.K.
>>    Tel: +44 (0) 208 606 4534
>>
>>    ______________________________________________________________________
>>
>>    Fujitsu Laboratories of Europe Limited
>>    Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
>>    Registered No. 4153469
>>
>>    This e-mail and any attachments are for the sole use of
>>    addressee(s) and
>>    may contain information which is privileged and confidential.
>>    Unauthorised
>>    use or copying for disclosure is strictly prohibited. The fact
>>    that this
>>    e-mail has been scanned by Trendmicro Interscan and McAfee
>>    Groupshield does
>>    not guarantee that it has not been intercepted or amended nor that
>>    it is
>>    virus-free.
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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/20090527/0a5eb7c9/attachment.html 