What behavior we encourage has little to do with whether the extension mechanism is there or not. I certainly think we need to encourage companies to work together with the community to define capabilities that will make it into core. We need to make sure that process works well and is open and fair. On the other hand, I don't want to end up with a backup feature that is the least common denominator simply because that's the only thing we can all agree on. I don't want to prevent companies and individuals to experiment and innovate with new features. At the end of the day, if a company wants to add feature, whether or not there is an extension mechanism, there is *nothing* that we can do to stop them. Extensions just give them the ability to add the new behavior in a manner that won't break clients. Extensions also provide a sandbox in which new capabilities can be tested before they make it to the core.
-jOrGe W. On Aug 23, 2011, at 1:51 PM, Soren Hansen wrote: > 2011/8/23 Jorge Williams <jorge.willi...@rackspace.com>: >> Imagine >> that Rackspace comes up with a feature to perform backups and places it in >> /backups. HP comes up with it's own backup feature and also puts it in >> /backups. The features are different so a client expecting Rackspace backup >> will break when it encounters an HP /backup. The idea of extensions is to >> prevent this from happening. > > This makes no sense to me. Keeping it in extensions, outside of core, > encourages *exactly* the behaviour you say it's meant to prevent. If > there's a /backup concept in core, you won't have these problems, > because everyone will have the same api for backups. If you reduce > core to some absolute minimum amount of stuff, you're encouraging (if > not in fact forcing) people deploying OpenStack to add each their own, > incompatible implementation of backups (or whichever other feature it > is that you're for some reason keeping out of core). How does the > extensions concept solve any of this? > > -- > Soren Hansen | http://linux2go.dk/ > Ubuntu Developer | http://www.ubuntu.com/ > OpenStack Developer | http://www.openstack.org/ This email may include confidential information. If you received it in error, please delete it. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
