On Jun 14, 2012, at 10:16 AM, Glen Campbell wrote: > My team is working on a set of language bindings for OpenStack and Rackspace > services. The first language we're working on is Python, and I'm trying to > come up with a simple, generic way to handle API extensions.
The first question that comes to mind is why duplicate effort with the rest of the community? We already have a comprehensive set of python bindings and would love to have some real development effort invested in them. > The method I've designed performs the following steps: > > it queries the /extensions resource for the particular service, > it converts the extension alias: value into a "pythonesque" name (converts > non-alphanumeric characters to underscores and lowercases everything), > it attempts to load a module from our plugins/ directory; if this fails, it > simply skips it > if it loads the module successfully, it instantiates a new class object with > the same name and passes the parent object to it > The plugin is responsible for modifying the parent object as needed to > support whatever changes occur in the extension. This seems sane. The biggest win here is to ensure that plugins can be installed using pip or distro packages. > As an example, to authenticate with Rackspace's Keystone implementation, you > need to use the RAX:KSKEY extension. Our language bindings would detect this > extension, load the file plugins/rax_kskey.py, and create a new object > rax_kskey(parent). The extension modifies the credentials-generation > reference in the parent object to point to its own implementation of the > credentials, and execution thereafter proceeds normally. If another provider > is used, then the extension won't exist and it will use the default Keystone > credentials. > > If this is a little confusing, I have some working code here: > https://github.com/rackspacedrg/openstack-python-sdk/tree/master/common (the > auth.py does the authentication, and extensions.py handles the extensions). > > The idea is that providers who supply extensions to the API can also provide > language-binding plugins ("adapters") for those extensions. > > Before I proceed too far down this path, however, I would like to know if > anyone else has developed a generic way of handling extensions (one that > could be extrapolated to other languages) and to solicit feedback on this > design. > > Glen Campbell • Developer Relations Group > glen.campb...@rackspace.com • (210) 446-9990 • @glenc > > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
