Mailing-List: contact deltacloud-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: deltacloud-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of dug@us.ibm.com designates
 32.97.110.149 as permitted sender)
In-Reply-To: <1297733017.4249.30.camel@avon.watzmann.net>
To: deltacloud-dev@incubator.apache.org
MIME-Version: 1.0
Subject: Re: [QUESTION] Alternative way how to use Deltacloud
From: Doug Davis <dug@us.ibm.com>
Message-ID: 
 <OF6EE233E2.CCA1D6F8-ON85257838.0013AA63-85257838.0014425D@us.ibm.com>
Date: Mon, 14 Feb 2011 22:41:17 -0500
Content-Type: multipart/alternative;
 boundary="=_alternative 0014406185257838_="

--=_alternative 0014406185257838_=
Content-Type: text/plain; charset="US-ASCII"

David Lutterkort <lutter@redhat.com> 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
--=_alternative 0014406185257838_=--