brian.waldon at rackspace
Jun 14, 2012, 10:26 AM
Post #2 of 4
(182 views)
Permalink
|
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.campbell [at] rackspace (210) 446-9990 @glenc
>
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
|
