[Libvir] Proposal for the storage API (for discussion only)

[Richard W.M. Jones]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20071019/16f18a0d/attachment-0001.bin>