[occi-wg] Format 1: Wire format or abstract model

[Sam Johnston]

On Wed, May 13, 2009 at 6:08 PM, Chris Webb <chris.webb at elastichosts.com>wrote:

> "Edmonds, AndrewX" <andrewx.edmonds at intel.com> writes:
>
> > So this one is a bit weird to me - even if you specific some on-the-wire
> > format it still has to conform to a model of some sorts - even if it's
> > implicit.
>
> My understanding of the two options is either OCCI is just a model without
> a
> rendering, or OCCI is a model together with a rendering. Clearly a
> rendering
> implies a model, as you say, and defining a rendering doesn't prevent us
> making the model explicit in a more abstract sense.


Right. I'd be surprised if the consensus were to be that we didn't need to
have both. The more interesting question for me is whether we simply map our
model to something that already exists (AtomPub) or build the whole thing
from scratch - which appears easy but isn't.

I well understand the traditional process of formally documenting a model
and then mechanically cranking out a wire protocol but the devil's in the
details, especially at scale (where a single enterprise can have as many
resources as ElasticHosts or even Amazon have in total). As an example, the
introduction of ETags in GData 2.0 saved these
guys<http://globelogger.com/2008/11/gdata-now-compliant-with-atompub.html>2
million calls a day - that sort of thing translates directly to wasted
money when you have engineers sitting around waiting and lose infastructure
agility (for example, machines losing sales because they take longer to
respond to load changes).

As a more concrete example, say I want to implement a desktop client for
managing any OCCI-compliant service. I'm going want to maintain a local
database of resources and at launch I'm going to want to check if anything's
changed and ideally retrieve only what has (it's an enterprise remember so
the initial load of millions of objects could take tens of minutes). How do
we implement that, and do I want to bother knowing that AtomPub already does
it <http://tools.ietf.org/html/rfc5023#section-9.5>?

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