Open Stack

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

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.

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.

Justin


On Tue, Apr 10, 2012 at 7:47 AM, Jay Pipes <jaypipes at gmail.com> wrote:

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