On Fri, Jun 21, 2013 at 3:46 PM, Vishvananda Ishaya <[email protected]>wrote:
> > On Jun 21, 2013, at 12:38 PM, Doug Hellmann <[email protected]> > wrote: > > > > > On Thu, Jun 20, 2013 at 2:00 PM, Vishvananda Ishaya <[email protected] > > wrote: > >> >> On Jun 20, 2013, at 10:22 AM, Brant Knudson <[email protected]> wrote: >> >> How about a mapping of JSON concepts to XML like: >> >> collections: >> <object> <pair name="pair-name"> the-value </pair> ... </object> >> <array> <element> the-value </element> ... </array> >> >> values: >> <string>text</string> >> <true/> >> <false/> >> <null/> >> <number>number</number> >> >> This type of mapping would remove any ambiguities. Ambiguities and >> complexity are problems I've seen with the XML-JSON mapping in Keystone. >> Plus the fact that it's so not-XML would convince users to switch to JSON. >> With a simple mapping, I don't think it would be necessary to test all the >> interfaces for both XML and JSON, just test the mapping code. >> >> >> +1 for something like this. JSON primary + autgenerated XML. I think the >> ideal version would be autogeneration of xml from jsonschema and some >> method for prettifying the xml representation via jsonschema tags. The >> jsonschema + tags approach is probably a bit further off (maybe for v4?), >> so having an auto conversion which is ugly but functional seems better than >> no XML support at all. >> >> Vish >> > > Let's please not invent something new for this. We're building a high > level platform. We shouldn't have to screw around with making so many low > level frameworks to do things for which tools already exist. WSME will > handle serialization, cleanly, in both XML and JSON already. Let's just use > that. > > Doug > > > Doug, > > Switching to WSME for v3 is out of scope at this point I think. Definitely > worth considering for v4 though. > > Vish > Absolutely - we agreed about that weeks ago. I assumed, however, that decision meant we would just continue to use the existing serialization code. I thought this discussion was moving toward writing something new, and I wanted to head that off. Doug > > > >> >> >> >> >> On Thu, Jun 20, 2013 at 11:11 AM, Jorge Williams < >> [email protected]> wrote: >> >>> >>> On Jun 20, 2013, at 10:51 AM, Russell Bryant wrote: >>> >>> > On 06/20/2013 11:20 AM, Brian Elliott wrote: >>> >> On Jun 19, 2013, at 7:34 PM, Christopher Yeoh <[email protected]> >>> wrote: >>> >> >>> >>> Hi, >>> >>> >>> >>> Just wondering what people thought about how necessary it is to keep >>> XML support for the Nova v3 API, given that if we want to drop it doing so >>> during the v2->v3 transition is pretty much the ideal time to do so. >>> >>> >>> >>> The current plan is to keep it and is what we have been doing so far >>> when porting extensions, but there are pretty obvious long term development >>> and test savings if we only have one API format to support. >>> >>> >>> >>> Regards, >>> >>> >>> >>> Chris >>> >>> >>> >> >>> >> Can we support CORBA? >>> >> >>> >> No really, it'd be great to drop support for it while we can. >>> > >>> > I agree personally ... but this has come up before, and when polling >>> the >>> > larger audience (and not just the dev list), there is still a large >>> > amount of demand for XML support (or at least that was my >>> > interpretation). So, I think it should stay. >>> > >>> > I'm all for anything that makes supporting both easier. It doesn't >>> have >>> > to be the ideal XML representation. If we wanted to adopt different >>> > formatting to make supporting it easier (automatic conversion from json >>> > in the code I guess), I'd be fine with that. >>> > >>> >>> >>> I agree, we can change the XML representation to make it easy to convert >>> between XML and JSON. If I could go back in time, that would definitely be >>> something I would do different. 3.0 gives us an opportunity to start over >>> in that regard. Extensions may still be "tricky" because you still want >>> to use namespaces, but having a simpler mapping may simplify the process of >>> supporting both. >>> >>> -jOrGe W. >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
