incubator-deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lutterkort <>
Subject Re: [QUESTION] Alternative way how to use Deltacloud
Date Wed, 16 Feb 2011 01:12:52 GMT
On Mon, 2011-02-14 at 22:41 -0500, Doug Davis wrote: 
> David Lutterkort <> 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?

That's two questions bundled into one ;) The first one is: why bother
with a REST API at all, rather than just implement a local library API ?
The big reason for that is that defining a REST API allows providers to
offer this API natively. It is definitely one of the goals of Deltacloud
to have providers offer the Deltacloud API as their public API, or at
the very least, an alternative to their proprietary API.

Given that the REST API has value in its own right, the next question
is: how can that API be consumed easily by a variety of clients ? Here
our answer is to provide client libraries in a variety of languages;
since most of the work is done on the server, clients should be fairly
simple and mostly concerned with translating REST into the
idiosyncrasies of the host language.

> 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.

There's really two big goals for Deltacloud: the most immediate need is
for an abstraction API that wraps existing cloud API's. That's what
we've focused on so far, and there's still a good amount of work to be
done in this area.

The second goal of Deltacloud though is no less important: providing a
proving ground for cloud API improvements, bringing user-driven
innovation to the mostly proprietary world of cloud API's. That goal can
only be addressed with some sort of web service API, for which we chose

> 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.

Besides the more philosophical ideas above, there's the practical
concern that Deltacloud today is written in Ruby, so the only really
working in-process use of Deltacloud would be from Ruby; sure, we could
rewrite Deltacloud in C, and then provide language bindings. That's a
lot of work, and straight up C-to-language-X bindings generally produce
very poor API's - it's tolerable when the C library provides
functionality that would otherwise be very hard to come by. But in the
case of cloud abstraction libraries, there's already a good number of
language-specific libraries, and I don't see what value Deltacloud would
add there.


View raw message