David Lutterkort wrote:
On Wed, 2009-07-08 at 22:57 -0400, Bob McWhirter wrote:
Let me propose that anything involving the REST/SOAP API is useful only if we have a service running.
Absolutely - my email were more musings about what latitude we have in implementing the API.
Though, I dunno if anyone else likes the idea of a handful of /bin/foo being the "library". I've got to think that backticks or exec() from python/ruby/perl wouldn't be worse than tossing XML to 127.0.0.1 just to ultimately power the same backend driver.
Command line tools tend to define the worst interface possible, much worse than some web service, with the result that error handling consists of little more than printing 'Something went wrong, sorry' - it's not a technical limitation, but well scriptable command line tools are few and far between.
Plus, no services to install or keep running.
No service would definitely be a big plus - what I am not clear about is what that means for implementing for libcloud: if the same driver/plumbing should run in a service and from the command line, I fear we'll either wind up spinning up half the service from the command line anyway, or write big abstractions to blur the difference between the two.
I still favor the architecture where libcloud is one big service that exposes its API in a variety of formats, with command line tools and language-specific client libraries/command line tools that talk to that service. Simplest deployment of the service (with possibly degraded functionality) should be literally 'yum install libcloud; service libcloud start'
Other deployment variations (like the ones in your diagrams) could be achieved with deploying the big service multiple times and configuring it differently (proxy, only some drivers enabled, reduced stateful functionality etc.)
Call me a wuss, but I'd rather work on one largish code base, than many loosely coupled services ;)
If we follow the one service, many drivers. I assume there would be client bits per language which all they do is expose a native view of the rest calls. So.. I assume the following:
# Get the core server $ yum install libcloud
# Get the cloud instance I want $ yum install libcloud-wickedCoolProvider
$ Get the client tech I want $ yum install libcloud-client-erlang
and away I go
-- bk