[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