On 06/08/2012 08:39 AM, Michal Privoznik wrote: >>> This API is called virDomainInterfacesAddresses (okay, maybe >>> too many plurals) and returns a dynamically allocated array >>> of virDomainInterface struct. The great disadvantage once >>> this gets released, it's written in stone and we cannot change >>> or add an item into it. Therefore we might add a padding into >>> it - something like reserved for future use. On the other hand, >>> everything important is already there - what else we will want >>> to add? :) >> >> How about returning an XML document instead of a struct? We've been >> burned by structs in the past... > > If we decide to go this way, then we should return JSON which is easier > to parse within C code. However, the most easy to use is current > proposal IMO.
We have a history of returning XML for anything that needs to be easily extensible. An application compiling against libvirt.so already has to know how to parse XML, but currently does not have to know how to parse JSON. I'd much rather stick with XML than make life harder for applications to learn two formats. I agree that XPath notation is a bit harder than direct field access, but I think the goal of future extensibility outweighs the goal of ease-of-representation if the simpler representation will lock us into an API nightmare. -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
