[occi-wg] Format 3: Meta-model around nouns, verbs and attributes

[Sam Johnston]

Ok first let's degooglify this, especially now we know Microsoft are behind
it as well:

On Wed, May 13, 2009 at 4:41 PM, Richard Davies <
richard.davies at elastichosts.com> wrote:

> Decision 3: For the core wire format(s), what meta-model should be adopted
> in rendering the nouns, verbs and attributes (i.e. a framework/style within
> which the nouns, verbs and attributes are rendered and any framework
> services are added):
> a) Minimal/no meta-model: Nouns, verbs and attributes are rendered as
>   directly as possible over HTTP in a very basic REST style.
> b) *AtomPub* meta-model: Nouns, verbs and attributes are rendered as *Atom
> *
>   objects and carried according to *Atom* conventions with *AtomPub*services.
> c) Other?
>

For a) you still need a meta-model, you may just end up writing one
yourself.


> Perspective of myself and Alexis: For the core wire format, OCCI should
> minimize the meta model so that the specification of the core wire format
> is
> as small as possible, and hence interoperability between OCCI-compliant
> clouds is easiest to demonstrate, test and debug.
>

It's a leap of faith to claim the one which is "as small as possible" is
also "easiest to demonstrate, test and debug" - this will rarely be the case
(framing, error checking, documentation, etc. always adds [good] fat).

I agree though with the assertion that "the core wire format [should be] as
small as possible", and would go so far as to say that even resources should
be extensions (there's no reason people shouldn't be able to use OCCI for
bare hypervisors or storage and network devices - an all-in-one protocol is
sure to cause problems there). That is, the core protocol should provide a
skeleton and nothing more... OCCI without resources would be like HTTP
without the verbs where implementors would take only the ones they need (as
is basically the case today), including ones they define themselves (like
EH's IP addresses that I maintain are unnecessary).

A useful data point is that Microsoft started going down something like the
POX (Plain Old XML) path with
web3s<http://dev.live.com/livedata/web3s.htm#_Toc165288985>and
this<http://www.25hoursaday.com/weblog/2008/02/28/WindowsLivePlatformNewsMicrosoftStandardizesOnAtomPubForWebServicesAndOtherStories.aspx>is
what they had to say about their about face adoption of AtomPub:

*The fact is when we listened to the community of Web developers the
> feedback was overwhelmingly clear that people would prefer if we worked
> together with the community to make AtomPub work for the scenarios we felt
> it wasn’t suited for than Microsoft creating a competing proprietary
> protocol.*
>

Here's what one innocent bystander <http://www.markbaker.ca/blog/about/> had
to say (better than I would have):

> *I’m confident this is for the best. In addition to Atom/APP being
> existing standards (with an accompanying abundance of existing tooling),
> Microsoft will also gain the evolutionary advantages of the hypermedia as
> the engine of application state constraint, which Web3S opted to replace
> with a schema-driven application model. Kudos to everybody involved in that
> decision.*
>
The world doesn't need YAFP (yet another protocol) - it's got more than it
can handle already - and even if it did I don't think this is the best group
to define it (hello IETF)... besides we've got better/more important things
to be doing than reinventing wheels.

As such I'd definitely go for (b) (almost) every time. If we had a small,
static set of stuff to do (think Twitter) then I might go for (a), but we
don't and we can't even hope to predict everything people will want/need to
do (besides, Twitter supports Atom, JSON and POX for most operations).

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090513/ecb19399/attachment.html