On Wed, May 13, 2009 at 6:08 PM, Chris Webb <chris.webb@elastichosts.com>wrote:
"Edmonds, AndrewX" <andrewx.edmonds@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