On Jul 29, 2013, at 5:56 PM, Andrew Phillips wrote: > 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.
Agreed. > 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. Zack did a great job of testing it and I think I covered the well-supported bit in my other email. ;) > @Everett: assuming you can share this information, do you have any details on > anyone outside Rackspace using jclouds with Trove? Not that I'm aware of. I'll see what I can do about starting to collect stats on this sort of stuff. Everett
