Open Stack

On Thu, Jun 20, 2013 at 2:00 PM, Vishvananda Ishaya
<vishvananda at gmail.com>wrote:

>
> On Jun 20, 2013, at 10:22 AM, Brant Knudson <blk at acm.org> 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


>
>
>
>
> On Thu, Jun 20, 2013 at 11:11 AM, Jorge Williams <
> jorge.williams at rackspace.com> 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 <cbkyeoh at gmail.com>
>> 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
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130621/8659ef6b/attachment.html>