Open Stack

On Fri, Jun 21, 2013 at 3:46 PM, Vishvananda Ishaya
<vishvananda at gmail.com>wrote:

>
> On Jun 21, 2013, at 12:38 PM, Doug Hellmann <doug.hellmann at dreamhost.com>
> wrote:
>
>
>
>
> 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
>
>
> 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 <
>> 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
>>
>>
> _______________________________________________
> 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/4e2cadf7/attachment.html>