Daniel Veillard wrote:
On Fri, Oct 19, 2007 at 09:53:27AM +0100, Richard W.M. Jones wrote:Daniel P. Berrange wrote:No, that doesn't make sense. XML for an API is a hack. It's hard toUsing structures in the public API is not in keeping with the rest of the libvirt APIs. We should be using XML for the main metadata description of volumes & pools.I disagree with you. XML is perfectly suitable for descriptions, especially when you need extendability and you can't control the future range of extensions. It's not proper for 'runtime' operations, but as a way to describe complex structures I find it fills its role perfectly.
These are not complex structures. It's a list of volumes, and each volume has 3 or 4 attributes (name, total size, free space, and a few flags).
A simple array of C structures can describe that.
use it without requiring an additional external library to parse the XML.not an argument, "Security is a hack it requires external libraries to implement right" , doesn't work :-)
This is not a relevant comment.
It's slow.For description, one time operation is absolutely not a problem. Plus libxml2 parses a 20+MBytes/s with current processors.It has the facade of maintaining ABI compatibility (because it's "just strings"), but in fact has no guaranteed ABI at all.You can't guarantee proper processing of something you can't describe in any case. Hard versionning with id in your stuctures can't guarantee anymore, if the code doesn't handle that version you're out.
I didn't explain this well, but the versioning is forwards compatible. The basic fields in the structure would still be there in future versions, and callers which did not understand the future version could still use the fields they understand. The presence of the updated version number would indicate (for future callers) that there are extra fields they can access appearing after the basic fields. Sorry for the poor original explanation of this.
BTW, this is precisely analogous to using XML, because you'd always want to provide the original XML fields for old callers, but with extra fields for new callers to use. It's just a lot simpler to use C structures, and allows for type safety, and removes the error-prone runtime failures of XML (what if a basic field you thought should be there is missing from the XML?).
> Actually
with XML you can still extract the part of the structure you understand. And you can similary put ids labels in the structure allowing to introduce a radical change like the difference between a Xen or KVM definition. I still maintain that using XML for description (domains and network) was the best approach which allowed to go forward 2 years ago even if most of what we use now is very different from what was available at the time. And in front of the wide variety of storage options, I guess it's still the best choise to describe how to reach the data you want to access. Once the attach has been done, sure XML would be a bad format for operations in most case. But for description, which is what Dan suggested I totally agree with him. Daniel
Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
smime.p7s
Description: S/MIME Cryptographic Signature
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
