On Fri, May 15, 2009 at 11:04 AM, Andre Merzky <andre@merzky.net> wrote:
An alternative, but somewhat more heavyweight/slower, and thus only ustified when there is vested interest from multiple sides:
* Extensible spec released, implementors have at it * MacroHard wants to talk about RAID levels for their upcoming BigDisk * It's not in the spec so they propose an extension package to us (aka OCCI-WG) * we discuss it, think it's a good idea (or not), and produce a formal specification document * implementors hack at it, and interop if proven by multiple implementations * JuniperBerry see MacroHard's BigDisk eating their lunch and want to add a similar feature to their LittleDisk * it's already specified so nothing needs to be done - bingo, interoperability
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 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. Sam