And let me finish with a question (or two). Is there strong agreement in the community that jclouds should very much emphasize (and restrict core) to APIs with cloud-agnostic abstraction layers?
I think we're learned over the years that premature abstraction is dangerous, especially in the area of new cloud service types and especially where there are initially only one or two examples to go on.
There are two levels of APIs in jclouds, however: the "top-level" abstractions compute, blobstore etc. and the things in the "apis" directory. Some of these, e.g. route53, don't implement any of the top-level abstractions, and so far this hasn't been a problem, from what I can see.
There was a similar discussion related to Chef [1] shortly before the ASF move, during which there also was tentative agreement on making Chef a "core" API without a corresponding top-level abstraction.
I don't see why Trove and RDS couldn't follow Route53, with a top-level abstraction being added once we have sufficient APIs and providers to choose from.
I should add that this, to me, is very much an orthogonal concern from stability and maintenance of the API itself: I fully share Matt's feeling that APIs should be stable, well-tested and well-supported before becoming part of the main jclouds project.
@Everett: assuming you can share this information, do you have any details on anyone outside Rackspace using jclouds with Trove?
ap [1] https://groups.google.com/forum/#!msg/jclouds-dev/AUCJoNrPD7M
