Richard, 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? a On Mon, May 11, 2009 at 6:12 PM, Richard Davies <richard@daviesmail.org> wrote:
Alexis,
This is an important distinction, thank you for highlighting and explaining.
Like Randy, my personal goals for OCCI are almost entirely for interop.
Today every cloud provider invents their own API to cover essentially identical functionality, and every cloud customer or tools vendor integrates independently with every cloud provider (c.f. Alexis' old employer CohesiveFT integrating with Amazon, FlexiScale, ElasticHosts, Sun, etc.)
If all we get out of OCCI is an interoperable API which multiple cloud providers actually adopt, then I would consider that a massive win for the customers and the ecosystem and hence for the cloud providers themselves.
I believe that making this interoperable API as minimal as possible will speed adoption and make it more likely that different implementations actually interoperate.
Cheers,
Richard.
Use case: http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/SingleTechnic... _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg