[occi-wg] Simple JSON rendering for OCCI
Andre Merzky
andre at merzky.net
Fri May 15 04:46:35 CDT 2009
Quoting [Sam Johnston] (May 15 2009):
>
> Yes, we would need both - registries primarily for change management of
> attributes, states, etc. and full-blown extensions for more advanced
> topics like adding new resource types/styles (e.g. load balancers).
> I'd suggest breaking up the workload as follows:
> * Adopt AtomPub (+search, caching, etc.) as OCCI Core - lots of hard
> work already done (the alternative will almost certainly involve
> another OGF cycle, pushing the final delivery out to OGF 28 which
> is yet to be scheduled in 2010)
> * Specify compute, storage and network resources as separate
> extensions (probably in that order)
> * Specify state control as an extension <- at this point we have our
> implementable draft
> * Specify billing, performance monitoring, etc. as extensions
> * Flesh out over time based on demand for features
Looks good to me. Although Atom, which you favour, is still
not decided upon ;-) Anyway, procedure and timeline look
sensible, IMHO.
FWIW, OGF28 should be around March 2010.
> One huge advantage of this approach is that we don't have to wait until
> the end before we start implementations - people can start right now
> (as I have).
>
> PS.: I am not sure if OGF would go into the space of
> maintaining registries, or such. OGF's business is to
> produce specification documents, and to host the
> infrastructure for doing so. But I am sure that, if a
> registry is the way to go, we'll find a host for that...
>
> One non-technical point to consider when it comes to things like
> registries is that using neutral ground like IANA make the standard far
> more likely to be adopted by other SSOs.
Yes, good point.
Andre.
> Sam
--
Nothing is ever easy.
More information about the occi-wg
mailing list