Jarret Raim wrote: >>I'm presuming that this is our last opportunity for API review - if >>this isn't the right occasion to bring this up, ignore me! > > I wouldn't agree here. The barbican API will be evolving over time as we > add new functionality. We will, of course, have to deal with backwards > compatibility and version as we do so.
I suggest that writing bindings for every major language, maintaining them through API revisions, and dealing with all the software that depends on your service is a much bigger undertaking than e.g. writing Barbican itself ;-) So it seems much more efficient to get v1 closer to right. I don't think this need turn into a huge upfront design project either; I'd just like to see the TC approve your project with an API that the PTLs have signed off on as meeting their known needs, rather than one that we know will need changes. Better to delay take-off than commit ourselves to rebuilding the engine in mid-flight. We don't need the functionality to be implemented in your first release, but the API should allow the known upcoming changes. > We're also looking at adopting the > model that Keystone uses for API blueprints where the API changes are > separate blueprints that are reviewed by a larger group than the > implementations. I think you should aspire to something greater than the adoption of Keystone V3. I'm sorry to pick on your project - I think it is much more important to OpenStack than many others, though that's a big part of why it is important to avoid API churn. The instability of our APIs is a huge barrier to OpenStack adoption. I'd love to see the TC review all breaking API changes, but I don't think we're set up that way. Justin _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
