I'd really rather we supported one format, if they're not going to be equal citizens (i.e. both generated from a common model).<div><br></div><div>I wasted a lot of time with nova's XML "support"; I'm sure the Java binding was the only project ever to try to use it; we'd have been able to proceed much faster if we'd just stuck with JSON - we now have a horrible hybrid, where JSON is used for some calls because the XML has/had bugs.</div>
<div><br><div>You prefer working from a JSON model; you're doing the work; so JSON it is.  Please spend the time you would have spent on XML support on making glance 2.0 the best image server there is.</div><div><br></div>
<div>Justin<br>
<br><br><div class="gmail_quote">On Tue, Apr 10, 2012 at 7:47 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
FWIW, Nova already has this kind of abstraction, with views and serializers... I wasn't planning on reinventing any wheels with the 2.0 Images API implementation; just using what Nova had (and hopefully moving it to openstack-common before bringing the code into Glance).<br>

<br>
Best,<br>
-jay<div class="im"><br>
<br>
On 04/10/2012 06:51 AM, Doug Hellmann wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<br>
On Mon, Apr 9, 2012 at 5:14 PM, Justin Santa Barbara<br></div><div><div class="h5">
<<a href="mailto:justin@fathomdb.com" target="_blank">justin@fathomdb.com</a> <mailto:<a href="mailto:justin@fathomdb.com" target="_blank">justin@fathomdb.com</a>>> wrote:<br>
<br>
            When you're designing JSON considering only JSON, you'd<br>
            probably use {<br>
<br>
            key1: value1 } - as you have done.  If you're designing<br>
            generically,<br>
            you'd probably use { key: key1, value: value1 }.<br>
<br>
<br>
        You mean we'd have to do dumb crap because XML doesn't have the<br>
        native concept of a list? ;)<br>
<br>
<br>
    XML has lists, as does Avro, ProtocolBuffers & Thrift.  XML supports<br>
    extensible lists, which is why the syntax is different.<br>
<br>
            You'd *think* this would work. In practice, however, it<br>
            really doesn't. Neither does (good, valid) code generation...<br>
<br>
<br>
    Of course it works!  Every JAX-RS webserver does this.  You just<br>
    can't start with JSON first and expect everything to magically be OK.<br>
<br>
    If you think it doesn't work, can you provide an example?<br>
<br>
    You start with an abstract model, and then check what it looks like<br>
    in JSON, in XML, in ProtocolBuffers, in Avro, in Thrift, in HPSTR,<br>
    etc...  If you start with JSON, then of course it won't work.  If<br>
    we're going to treat XML as an afterthought, then I'd rather we just<br>
    didn't support XML at all (and yes, I absolutely mean that - it is<br>
    good that Glance is honest that they don't support XML.)<br>
<br>
<br>
Kevin Dangoor and Christophe de Vienne have done some work on<br>
abstracting the view of data inside and outside of the API with<br>
TGWebServices [1] (a TurboGears add-on) and the more recent "Web<br>
Services Made Easy" [2], which is framework agnostic. I have used TGWS<br>
in the past to create an API using SOAP and JSON (it also supports<br>
generic XML, but we didn't need that). I found that it worked well for<br>
our purposes at the time.<br>
<br>
[1] <a href="http://code.google.com/p/tgws/" target="_blank">http://code.google.com/p/tgws/</a><br>
[2] <a href="http://packages.python.org/WSME/" target="_blank">http://packages.python.org/<u></u>WSME/</a><br>
</div></div></blockquote>
</blockquote></div><br></div></div>