At its heart, Deltacloud is about providing a single API to access resources on multiple cloud providers. Making Deltacloud's core engine more consumable (via native language bindings in addition to HTTP) will only help that goal. Plus, offering a single-hop option to leverage Deltacloud improves performance and convenience (no need to set up a DC server).
- Eric W. On Feb 14, 2011, at 10:41 PM, Doug Davis wrote: > David Lutterkort <[email protected]> wrote on 02/14/2011 08:23:37 PM: > ... >>> It seems to me like a way how 'fog' or 'libcloud' is going and I'm not > sure >>> if we want to support this way as well. >> >> I don't want to go that way - we should stress that the value of >> Deltacloud lies in (a) the REST API and (b) that all the heavy lifting >> is done on the server, keeping the clients very simple. > > David, > can you elaborate on this? What's the benefit of the REST API? It > would > seem to me that the benefit is the abstraction layer above all of the > providers > regardless of whether its being presented via REST, Ruby, Java, or > whatever. > IMO, what people are looking for is the ability to talk to multiple > providers > with minimal specialization code. Seems to me that offering them the > choice > of an http-hop model vs a client-side-adapter model should be left up to > the > client to decide. Not everyone likes or can support a multi-hop model. > Either way, let them make the choice but whatever they choose give them > the > benefits of the DeltaCloud engine. > > thanks, > -Doug
