I'm not really an active nova contributor as of yet, but I'll +1 this if nova's XML support is anything like what I see in trove (which I believe just cloned how nova did it in the first place). XML without a schema is terrible for a serialization format. In my experience, the only people who actually use XML really want SOAP or XMLRPC (mostly .net and Java developers), which both give mechanisms for defining the schema of the request/response so data types like arrays and dates and booleans are sane to work with. Doing XML in a generic fashion never adequately deals with those problems and is then rarely, if ever, actually used.
Greg On Jan 13, 2014, at 8:38 AM, Sean Dague <s...@dague.net> wrote: > I know we've been here before, but I want to raise this again while there is > still time left in icehouse. > > I would like to propose that the Nova v3 API removes the XML payload > entirely. It adds complexity to the Nova code, and it requires duplicating > all our test resources, because we need to do everything onces for JSON and > once for XML. Even worse, the dual payload strategy that nova employed leaked > out to a lot of other projects, so they now think maintaining 2 payloads is a > good thing (which I would argue it is not). > > As we started talking about reducing tempest concurrency in the gate, I was > starting to think a lot about what we could shed that would let us keep up a > high level of testing, but bring our overall time back down. The fact that > Nova provides an extremely wide testing surface makes this challenging. > > I think it would be a much better situation if the Nova API is a single > payload type. The work on the jsonschema validation is also something where I > think we could get to a fully discoverable API, which would be huge. > > If we never ship v3 API with XML as stable, we can deprecate it entirely, and > let it die with v2 ( probably a year out ). > > -Sean > > -- > Sean Dague > Samsung Research America > s...@dague.net / sean.da...@samsung.com > http://dague.net > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
