It's easy when each new version is defined by a central body. The problem we face is that we want to allow HP, Rackspace, Nexenta etc to define their own extensions, without serializing through a central body. Some extensions may only apply to private clouds and never be shared publicly.
This is a bit like ZFS feature flags, to use an example that should be near and dear to your heart! On Fri, Apr 13, 2012 at 2:24 PM, Caitlin Bestler < caitlin.best...@nexenta.com> wrote: > Exactly what do you see as the required “non-linear extensibility”?**** > > ** ** > > These are ultimately requests to a server. Each new extension is coded in > that server.**** > > There is no value in a client making up its own extensions that are not > understood by the server.**** > > ** ** > > What is relevant is a server continuing to support clients that have not > yet been updated to > understand a new format.**** > > ** ** > > As I stated in my first post, that problem was solved in ANSI C. > Python/JSON is trivial.**** > > ** ** >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp