openstack team mailing list archive

[Justin Santa Barbara <justin@xxxxxxxxxxxx>]

>
> Justin, what does "design a model which works with XML" mean?


Simply avoiding the handful of things that are specific to JSON (or
specific to XML).  Nothing too onerous (no angle brackets)!


> I think this is only done in the image properties.
>>
>
> No, the image properties have been removed in the 2.0 Images API and
> replaced with the standard concept of "tags":
>
> https://docs.google.com/**document/d/1rb7ZVn0Du_**
> 5NZqUyQpqUZSmv7Qd66TMHYAtvsow7**LH4/edit#heading=h.**y10rq9pdt27y<https://docs.google.com/document/d/1rb7ZVn0Du_5NZqUyQpqUZSmv7Qd66TMHYAtvsow7LH4/edit#heading=h.y10rq9pdt27y>


I was looking at properties in "GET /schemas/image/access" and "GET
/schemas/access".  In general, the Glance 2.0 model is very close to being
XML-compatible.

 On the downside: The JSON isn't as JSON-ic as it could be.
>>
>
> In what ways?


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

 On the upside: You need never worry about XML again
>>
>
> We haven't worried about it at all up until now. And Glance has been
> perfectly fine without it. ;)
>

Well yes, I agree that our XML support generally is sufficiently buggy as
to be unusable, hence unused.  I don't actually care about XML, I just care
about having a well-specified API that works.

In my opinion, the way to do that is to specify a model, and we have JSON
and XML representations of that model.  If we design the model right, JSON
& XML both "just work" without any code (and less code = less bugs).
 Moreover, when someone introduces another data interchange format, we
again just write one piece of middleware, one documentation generator, and
we're done.  Doing this by hand for each format is simply busywork.

I don't care whether we specify the model as a Python class, Java class,
XML schema, JSON schema, or using stick figures with long arms pointing at
boxes.  You can even specify it in JSON if you stick to a "lowest common
denominator" subset.  I think the only thing you need to avoid is "no
changing-at-runtime keys"; I think this makes it compatible with XML, Avro,
ProtocolBuffers & Thrift.

I don't think it should be a big deal for the JSON format to avoid dynamic
keys, given how much you win whenever you have to support a new format.

Incidentally, I just heard about yet another new format - apparently this
one is going to be the standard for use with node.js
- Hypertext-Powered-State-Transfer-Representation.  Apparently JSON is too
complicated now - with its strict need for quote marks and multiple data
types and all that over engineering, so HPSTR just sends the values; you
just use convention over configuration to infer the keys.  I trust it's not
going to be a lot of work for OpenStack to support it.

> See you in a week!

Looking forward to it!