Open Stack

See comments in-line below.

-----Original Message-----
From: Jay Pipes [mailto:jaypipes at gmail.com] 
Sent: Saturday, August 25, 2012 3:32 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [Quantum] About XML support in Quantum v2 API

On 08/16/2012 07:33 PM, Paul McMillan wrote:
> On 08/16/2012 04:20 PM, Edgar Magana (eperdomo) wrote:
>> So, is there any rush on having XML support for Folsom? I would say NO.
>> I think we should carefully review what we are supporting for Folsom 
>> because it's going to be our "debut" as core project and the last 
>> thing that we want is a service that offers a lot of features but with bugs.
> 
> As Edgar said, it makes sense to add XML support when it's feature 
> complete and stable, rather than rushing in a half-baked API which 
> then must be supported.

++. And I would add that those who desire the XML format support should
do the coding. We've seen what happens when developers who don't work with XML every day try to add support for it -- and try to maintain it afterwards.
[Hochmuth, Roland M] I agree. See proposal below.

This is the reason Glance never supported XML. The developers of Glance don't work with XML and we didn't want to add a half-baked format that we weren't comfortable with maintaining.

I understand George Reese believes this makes Glance itself half-baked, but there hasn't been anyone demanding XML format support in Glance yet that hasn't easily and simply used the JSON format that Glance already supports. In other words, people asked for XML support in Glance to check off some "enterprise checklist", but when push came to shove, nobody really needed it to begin with.

 [Hochmuth, Roland M] I've spoken with several folks at HP about this. The consensus is that XML is very important for enterprise customers and if not supported will present a barrier to more wide-spread adoption within the enterprise. If XML is supported OpenStack becomes much more consumable in the enterprise.

The only tenable solution proposed for this -- and I'm not sure whether it was George who suggested it or someone else -- is to have XML serialization driven from a JSON converter, so that you don't have to maintain multiple format definitions, only the JSON format definition that can be translated to XML. That way you don't need to maintain lots of code, only a decent JSON -> XML translation engine that feasibly could go into openstack-common...

 [Hochmuth, Roland M] I also agree that this sounds like it would be a good approach and it is commonly used. There are several Python XML converters that we could look into leveraging. Do we know if the JSON can always be translated to XML for the case of the OpenStack API? I'm just wondering if this approach was already investigated but not used for some reason, as in there are some show-stoppers. Unless someone else would like to own this area, as it doesn't seem to be covered yet, I would be happy to volunteer to investigate this area further and propose a blueprint... I'll be attending the OpenStack conference so that would be a good time to sync-up and run a session on this topic, if there is enough interest, and implement in Grizzly.

Best,
-jay

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev