Further discussion in #libcloud has lead us to think (but no decisions yet!) about instead of "drivers" being implementation details, but rather have them be running services that directly speak libcloud-API on one side, and the cloud-native API on the other.
In this case, Steve the Scripter would fire up the driver service he's using today, perhaps on localhost, and work with a cloudsh or other client that talks REST to the localhost-hosted service.
For the value-add of the previously discussed generic libcloud- service, which might do credential mapping and cloud multiplexing, it would be another cloud that speaks libcloud-API on the front, but also talks libcloud-API out the back ultimately to the real driver services.
In this case, libcloud-service would act more as a proxy/aggregator, and not directly drive the drivers.
One benefit is the RHEV-M driver would be able to run fully on the win32 machine, colocated with RHEV-M. It'd be a separate process from RHEV-M, but would not require a "driver" to be placed in libcloud- service AND a shim placed on the win32 machine. The full driver would be a single process running on the win32 box, aggregated by the libcloud-service.
If libcloud-service is a proxy, we *could* end up chaining them together, such as a libcloud-service for each department, which talks to its own local clouds AND also the libcloud-service for the corporation. The libcloud-service for the corporation would then also talk to its own clouds.
If each driver is really a service, and we stitch them together, we're SOA buzzword compliant. And each driver can be authored in the language most appropriate for that driver.
In previous discussion, if libcloud-service directly spoke to the drivers in-process, that severely restricts the implementation choices.
Here's some diagrams:
http://fnokd.com/~bob/libcloud-soa-1.png
The first represents Steve the Scripter who just wants a homogenous API he can script against regardless of which cloud he's really using. It would require 1 service running, possibly on localhost (but not required!).
The bottom half of that diagram shows a more complex configuration, where a proxying/aggregating value-add libcloud-service stands between Don the Developer and several clouds available simultaneously through the service.
Each driver may be on the same host, or may be exposed by the cloud provider natively, or distributed within the organization as appropriate (ie, RHEV-M's driver sitting directly on a win32 machine, everything else is scattered on linux boxen).
To make life easy for folks who are happy to use whatever language we've picked, we can also provide a libcloud-service-framework. This would be a template implementation of a driver, lacking the actual guts that do real work, but otherwise handling the HTTP and REST aspects.
http://fnokd.com/~bob/libcloud-framework-1.png
Folks could simply ignore it, though, and do their own implementation between libcloud-API and native-API. It's just an optional chunk to help driver implementors if they so choose.
-Bob