openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

On Fri, Apr 13, 2012 at 4:20 PM, Justin Santa Barbara
<justin@xxxxxxxxxxxx>wrote:

> 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.
>
>
Does that mean that an extension cannot add properties to an existing
object (such as adding a new attribute an Image), or just that all of those
properties will be an a nested object (such as
Image.my_extension.my_attribute)?


>
>    - 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 ;-)
>

Probably the same way. I would use setuptools entry points to map namespace
prefixes to the class, so the client could load the handler automatically
when it encounters data it does not recognize.


>
> 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
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>