openstack team mailing list archive

[Jorge Williams <jorge.williams@xxxxxxxxxxxxx>]

On Apr 13, 2012, at 3:20 PM, Justin Santa Barbara wrote:

My understanding is that the solution we have now is that any extension goes into its own namespace; we assign a prefix to the namespace and have a way to map that prefix to the full namespace.  (Similar to XML schemas).  Currently prefixes are hard-coded, but we may not be able to keep doing this forever (XML has pre-document prefixes to avoid the need for a central authority).

I see 3 questions:
1) Is my summary correct?

It's pretty close.  I did propose that we maintain a registry of prefixes, but that's never taken off.

I did a write up a while back on extensions, you can find it here:  https://github.com/RackerWilliams/OpenStack-Extensions/blob/master/apix-intro.pdf

Take the document that's in GitHub with a grain of salt, it doesn't entirely reflect the reality of things as they stand now and I feel,  after working with extensions for a while, that we need to make some slight modifications.
  It wasn't clear in the beginning where extension would be most useful so we added extensibility to everything.   As Mark mentioned, it's clear now that we need to scale down the points of extensibility.  In some cases we may introduce barriers to devs if we make absolutely everything extensible. In other cases, defining our own extensibility doesn't make sense.  For example,  there's no need define a way of extending HTTP headers -- first because, no one is writing those kinds of extensions and also because there already exists a method of extending  headers in HTTP so there's no need us to reinvent the wheel.  Stuff like that.


2) Are there any problems with the solution?

Yes a couple.  Especially when you consider what happens when an extension gets promoted to a full feature in a new version of the API.  I'm now leaning towards keeping prefixes forever...and providing a way for folks to write extension without a prefix, provided that they register the extension with the PTL of the project -- lets face it this is the sort of stuff that's happening now anyway.   Mind you these are all just thoughts at the moment we should have a larger discussion.

3) Are there any other problems we're not addressing?

Probably  :-)

We're having a panel on extensions at the summit.  We should discuss in detail then.

As one of the two authors of the Java binding, I can tell you how I plan on dealing with extensions:


  *   Map the JSON/XML/HPSTR to a strongly-typed model (so the representation is irrelevant to the consumer of the Java library).
  *   Each (known) extension has its own strongly-typed model object.
  *   These are stored in a registry.
  *   When we come across an extension, we look it up in the registry and either bind or ignore it.
  *   Every model object has an "Extensions" collection, which can be queried by type, to see if that extension data was present.

(Note: this has mostly been tested with the XML)


When you say registry, do you mean maven?


The nice thing about this is that a consumer of the library can write a binding for an extension, and register it with the client library, and "it just works".  So, even if you have a private extension, which you tell nobody about and run only on your private cloud, you can use it with the stock Java library.

That sounds like a really great approach!  I'd love to check out the nitty-gritty details...Are you documenting this somewhere?


Now, how you would do something that awesome in Python, I don't know ;-)


I'm sure there are Pythonistas out there working to figure it out.

-jOrGe W.