[occi-wg] William Vambenepe: Missing out on the OCCI fun

[Sam Johnston]

Thankyou to William Vambenepe, Tim Bray and other seasoned standards boffins
for their advice and contributions from the sidelines. I understand and
appreciate their preference to work at a "meta level" and value whatever
feedback they care to provide, including this insightful post that's hot off
the press:

Missing out on the OCCI fun

As a recovering “design by committee” offender I have to be careful when
lurking near standards groups mailing list, for fear my instincts may take
over and I might join the fray. But tonight a few tweets containing alluring
words like “header” and
“metadata”<http://twitter.com/samj/status/5037202759>got the better of
me and sent me plowing through a long and heated
discussion thread<http://www.ogf.org/pipermail/occi-wg/2009-October/thread.html#1315>in
the OGF OCCI mailing list archive.

I found the discussion fascinating, both from a technical perspective and a
theatrical perspective.

Technically, the discussion is about whether to use HTTP headers to carry
“metadata” (by which I think they  mean everything that’s not part of the
business payload, e.g. an OVF document or other domain-specific payload). I
don’t have enough context on the specific proposal to care to express my
opinion on its merits, but what I find very interesting is that this shines
another light on the age-old issue of how to carry non-payload info when
designing a protocol. Whatever you call these data fields, you have to
specify (by decreasing order of architectural importance):

   - How you deal with unknown fields: mustUnderstand or mustIgnore
   semantics.
   - How you keep them apart (prevent two people defining fields by the same
   name, telling different versions apart).
   - How you parse their content (and are they all parsed in the same manner
   or is it specific to each field).
   - Where they go.

SOAP provides one set of answers.

   - They go at the top of the XML doc, in a section called the SOAP header.
   - They are XML-formatted.
   - They are namespace-qualified.
   - You can tag each one with a mustUnderstand attribute to force any
   consumer who doesn’t understand them to fault.

You may agree or not with the approach SOAP took, but it’s important to
realize that at its core SOAP is just this: the answer (in the form of the
SOAP processing model) to these simple questions (here is more about the
SOAP processing model and the abuses it has
suffered<http://stage.vambenepe.com/archives/118>if you’re
interested). WSDL is something else. The WS-* stack is also
something else. It’s probably too late to rescue SOAP from these
associations, but I wanted to point this out for the record.

Whatever you answer to the four “non-payload data fields” questions above,
there are many practical concerns that you have to consider when validating
your proposal. They may not all be relevant to your use case, but then
explicitly decide that they are not. They are things like:

   - Performance
   - Ability to process in a stream-based system
   - Ease of development (tool support, runtime accessibility…)
   - Ease of debugging
   - Field length limitations
   - Security
   - Ability to structure the data in the fields
   - Ability to use different transports (way overplayed in SOAP, but not
   totally irrelevant either)
   - Ability to survive intermediaries / proxies

Now leaving the technology aside, this OCCI email thread is also interesting
from a human and organizational perspective. Another take on the good
old Commedia
dell standarte <http://stage.vambenepe.com/archives/96>. Again, I don’t have
enough context in the history of this specific group to have an opinion
about the dynamics. I’ll just say that things are a bit more “free-flowing”
than when people like my friend Dave Snelling were in charge in OGF. In any
case, it’s great that the debate is taking place in public. If it had been a
closed discussion they probably would not have benefited from Tim Bray
dropping in to share his experience. On the plus side, they would have
avoided my pontifications…
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20091021/30169950/attachment.html