← Back to team overview

openstack team mailing list archive

Re: Image API v2 Draft 4

 

+1 on reusing existing code and the move

On Tue, Apr 10, 2012 at 10:47 AM, Jay Pipes <jaypipes@xxxxxxxxx> 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@xxxxxxxxxxxx <mailto:justin@xxxxxxxxxxxx>> 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/>
>>
>

References