I think we should define more clearly, by examples, what it means for two implementations to interoperate and how they would use OCCI to do so, yet retain the right to extend their user APIs arbitrarily.
Any thoughts on an example for - say - EH and EC2?
EH and GG is probably the right example, given that Randy is on this list! What it would mean for me is that the same client code works against both clouds for core functionality. For example, if we take the Simple JSON Rendering which I just posted http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/SimpleJSONRen... then I'd like to see a HTTP GET against our respective endpoints returning the same format JSON list of nouns, with the same names for the same core attributes (id, title, cores, etc.). I'd also like to see the same core verbs at the same actuator URLs - e.g. http://api.example.com/<id>/stop would stop a server on both clouds. This doesn't sound much, but it's a long way ahead of where we are today! As an example of vendor extensions, EH supports VNC access to servers, and GG supports load balancers. This likely means that EH would have a couple of extra attributes on a server (e.g. the VNC password), and GG would have a couple of extra attributes on a network (load balancer configuration) + possibly some verbs. We'd reserve part of the namespace for nouns, verbs and attributes for these vendor extensions. For example, our VNC attribute on a server might be: vx_com.elastichosts_vncpassword and Randy's load balancer attributes on a network might be within: vx_com.gogrid_XXXXX with any verbs he needs within http://api.example.com/<id>/vx/com.gogrid/XXXX Randy - would this kind of scheme work for you? Cheers, Richard.