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

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to