openstack team mailing list archive

[Justin Santa Barbara <justin@xxxxxxxxxxxx>]

I don't think that works for non-linear extensibility...

I would be very happy if we could agree out how we're going to deal with
extensibility in JSON.  It is easy to support XML & JSON & any future
formats, and have them all be nice if there's willingness to do so, but
there's not, so let's drop it and focus on "stuff that matters"!

I believe we have a solution now for JSON extensibility (thanks Jorge),
it's not as "complete" as XML (read into that what you will) but it seems
to work fine.

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?
2) Are there any problems with the solution?
3) Are there any other problems we're not addressing?


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)

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.

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

Justin



On Fri, Apr 13, 2012 at 11:53 AM, Caitlin Bestler <
Caitlin.Bestler@xxxxxxxxxxx> wrote:

> The argument that XML has better extensibility than JSON isn't very
> convincing to my ears.
>
> I'm an old war horse, and recall extending message formats in ANSI C so as
> to maintain backwards
> compatibility with existing clients (by versioning the struct name itself
> and always keeping the same
> fields up front).
>
> If this problem could be solved in ANSI C, the solutions available to
> Python with JSON can only be better.
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>