I don't think that works for non-linear extensibility...<div><br></div><div>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"!</div>
<div><br></div><div>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.</div><div><br></div><div>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).</div>
<div><br></div><div>I see 3 questions:</div><div>1) Is my summary correct?</div><div>2) Are there any problems with the solution?</div><div>3) Are there any other problems we're not addressing?</div><div><br></div><div>
<br></div><div>As one of the two authors of the Java binding, I can tell you how I plan on dealing with extensions:</div><div><br></div><div><ul><li>Map the JSON/XML/HPSTR to a strongly-typed model (so the representation is irrelevant to the consumer of the Java library). </li>
<li>Each (known) extension has its own strongly-typed model object.</li><li>These are stored in a registry.</li><li>When we come across an extension, we look it up in the registry and either bind or ignore it.</li><li>Every model object has an "Extensions" collection, which can be queried by type, to see if that extension data was present.</li>
</ul></div><div><br></div><div>(Note: this has mostly been tested with the XML)</div><div><br></div><div>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.</div>
<div><br></div><div>Now, how you would do something that awesome in Python, I don't know ;-)</div><div><br><div>Justin<br><br>
<br><br><div class="gmail_quote">On Fri, Apr 13, 2012 at 11:53 AM, Caitlin Bestler <span dir="ltr"><<a href="mailto:Caitlin.Bestler@nexenta.com">Caitlin.Bestler@nexenta.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The argument that XML has better extensibility than JSON isn't very convincing to my ears.<br>
<br>
I'm an old war horse, and recall extending message formats in ANSI C so as to maintain backwards<br>
compatibility with existing clients (by versioning the struct name itself and always keeping the same<br>
fields up front).<br>
<br>
If this problem could be solved in ANSI C, the solutions available to Python with JSON can only be better.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div></div></blockquote></div><br></div></div>