On Fri, Apr 13, 2012 at 4:20 PM, Justin Santa Barbara <jus...@fathomdb.com>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.best...@nexenta.com> 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@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 > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
