[Libvir] [RFC] Host and guest capabilities

[Richard W.M. Jones]

Daniel Veillard wrote:
> On Wed, Mar 07, 2007 at 02:56:47PM +0000, Richard W.M. Jones wrote:
>> Daniel Veillard wrote:
>>>  This sounds too variable, adding an entry point per capability of
>>> some of the hypervisor available will lead to just too many entry points
>>> once the set of virtualization engines and associated benefits increase.
>>> That's one of the places where I feel wy more comfortable returning an
>>> XML description which can then be augmented as more features are added.
>> But this API is _precisely_ designed to be extensible.  The 
>> virCapabilities structure is not accessible to callers (unlike, say, 
>> virNodeInfo), except through accessor functions.  We can add accessor 
>> functions in future.
>>
>> Returning XML just punts the problem elsewhere.  Now clients need to 
>> worry about parsing the XML, and there's no real guarantee that the XML 
>> won't change in a way which is incompatible with the clients.  Whereas 
>> by using ordinary functions we have that guarantee.
> 
>   It's easier to make that garantee at the XML level in my opinion.

Well one can certainly be careful about future changes to the XML, but 
there is no guarantee for clients, not even the (very minimal) 
guarantees that C linking makes.  After all "char *getXMLBlob ()" will 
still link perfectly fine no matter what's in the XML.

> And adding pile of accessor functions for a struct that you don't feel
> you can define well enough to export is not the way I like to define APIs.

I would gladly make the structure public.  The original proposal which 
unfortunately didn't make it beyond some private chat was to prototype 
the call so it would be called as:

   struct virCapabilities caps;
   virConnectGetCapabilities (conn, &caps, sizeof caps);

This provides forwards compatibility because libvirt can add further 
fields to the structure, and libvirt can always tell which version of 
the structure that the client was linked against through the size field.

Future elements of the structure can even override earlier elements, for 
future clients which understand this.

The participants in the chat decided they preferred accessor functions 
instead, and since those are still type-safe I did not demur.

Anyway, to be honest I'm not that bothered.  If you think XML is better, 
I'm quite happy to return XML blobs.  My main concern is to get 
virt-manager working sensibly in the remote case.

Rich.

-- 
Emerging Technologies, Red Hat  http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF     Mobile: +44 7866 314 421
  "[Negative numbers] darken the very whole doctrines of the equations
  and make dark of the things which are in their nature excessively
  obvious and simple" (Francis Maseres FRS, mathematician, 1759)
-------------- 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/20070307/51f554a6/attachment-0001.bin>