openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #15706
Re: [nova] Call for Help -- OpenStack API XML Support
> -----Original Message-----
> From: openstack-
> bounces+gabe.westmaas=rackspace.com@xxxxxxxxxxxxxxxxxxx
> [mailto:openstack-
> bounces+gabe.westmaas=rackspace.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Gabe Westmaas
> Sent: Friday, August 10, 2012 9:15 AM
> To: Daniel P. Berrange; Vishvananda Ishaya
> Cc: OpenStack Development Mailing List; openstack@xxxxxxxxxxxxxxxxxxx
> (openstack@xxxxxxxxxxxxxxxxxxx)
> Subject: Re: [Openstack] [nova] Call for Help -- OpenStack API XML Support
>
>
>
> > -----Original Message-----
> > From: openstack-
> > bounces+gabe.westmaas=rackspace.com@xxxxxxxxxxxxxxxxxxx
> > [mailto:openstack-
> > bounces+gabe.westmaas=rackspace.com@xxxxxxxxxxxxxxxxxxx] On Behalf
> Of
> > Daniel P. Berrange
> > Sent: Friday, August 10, 2012 8:48 AM
> > To: Vishvananda Ishaya
> > Cc: OpenStack Development Mailing List; openstack@xxxxxxxxxxxxxxxxxxx
> > (openstack@xxxxxxxxxxxxxxxxxxx)
> > Subject: Re: [Openstack] [nova] Call for Help -- OpenStack API XML
> > Support
> >
> > On Thu, Aug 09, 2012 at 03:25:01PM -0700, Vishvananda Ishaya wrote:
> > > Hello Everyone,
> > >
> > > We are in the unfortunate position of not knowing how good our
> > > OpenStack API XML support is. All of our integration tests use json.
> > > Many of the compute extensions don't even have XML deserializers. We
> > > also assume that there bugs we don't even know about due to underuse.
> > > We need to do something about XML by Folsom, because releasing a
> > > buggy
> > api isn't good for anyone.
> >
> > I don't know this area of Nova code at all, but I must say I'm
> > surprised that it actually needs explicit extra work to accept or output XML,
> instead of JSON.
> > It should be possible to auto generate an XML document from a JSON
> > document, and vica-verca.
> > At which point you'd not need to have 2 sets of tests for JSON vs XML,
> > all you need test is the XML<->JSON conversions.
> >
> > I can imagine this isn't done because of a need to maintain compat
> > with some special XML schema that isn't a direct 1-1 mapping from the
> JSON schema ?
> > Are there other complications preventing this being done
>
> Correct. Extensions also cause some issues, though it all basically comes back
> to not being a 1-1 mapping. The reason it's not 1-1 is not because of different
> data, but just the representation of the same data.
>
> >
> > > 1) We get a lot of community support and we manage to get XML into
> > usable shape by Folsom.
> > >
> > > 2) We get enough community support to get the core api working and
> > > the
> > most important extensions in place. We release clear documentation on
> > what is expected to work.
> > >
> > > 3) We get no support, in which case we mark XML support deprecated
> > > and
> > encourage people to use JSON only.
> >
> > 4) Deprecate the current XML schemas, and declare new XML schemas
> > which are a 1-1 mapping from the JSON
>
> The biggest problem with this is that either json or XML ends up feeling
> second class. If you were writing XML for XML's sake it wouldn't come out
> looking like XML generated from json schemas. I will say that the reason it
> came out like this in the current API is that XML was first class with auto-
> generated JSON, which was pretty bad. Rather than going the other way, we
> opted to keep both optimized for development against the API rather than
> for development of the API.
>
> Anyway, not saying it can't be done, but I am saying that XML will feel like a
> second class format. This mostly has to do with figuring out when something
> should be an attribute of an element vs when it should be a value of an
> element. I think we ran into some issues around collections that were non-
> auto-translatable as well, but I'm struggling to remember them.
>
> We can decide to just pick a translation and go with it, of course. Although
> perhaps we need an expert on enterprise tools to make sure that the XML
> we generate properly translates into sane objects in those enterprise tools.
>
Oh, and, even if we do this, that does not remove the need for additional tests around XML, of course. We still need to make sure that is working correctly.
> >
> > > Note that other openstack projects only support json, and there are
> > > already java bindings that use json so option 3) isn't terrible, but
> > > we don't want to go that route without discussing it with the
> > > community first. If anyone has alternative solutions or suggestions,
> > > feel free to let me know.
> >
> > If we can get to a position where we auto-generate XML from JSON for
> > Nova, we could do the same for other projects too
> >
> > Regards,
> > Daniel
> > --
> > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/
> :|
> > |: http://libvirt.org -o- http://virt-manager.org :|
> > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
> > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~openstack
> > More help : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
References