Re: [Libvir] Proposal for the storage API (for discussion only)
Daniel Veillard wrote:
On Fri, Oct 19, 2007 at 09:53:27AM +0100, Richard W.M. Jones wrote:
> Daniel P. Berrange wrote:
>> Using 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.
> No, that doesn't make sense. XML for an API is a hack. It's hard to
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
Attachments:
- smime.p7s (application/x-pkcs7-signature — 3.2 KB)