[libvirt] Re: Libvir-list Digest, Vol 32, Issue 7

[Daniel P. Berrange]

On Fri, Jul 04, 2008 at 09:23:36PM +0200, T?th Istv?n wrote:
> You can see how Daniel Schweger's added functionality is meant to be 
> used in the srtc/testclient/org/libvirt/TestXen.java file.



> The way I imagined the java-libvirt architecture is that there is a 
> lower 'core' level, which is basically a function-for function 
> equivalent of the C libvirt functionality, with the bare minimum of 
> object-orientedness thrown in to pass for a proper java library (the 
> current libvirt in CVS)

Yep, I agree the core libvirt-java code should merely be a 1-to-1
mapping of C apis into Java objects.

> Plus, there should/can be anotherl API, that exposes the XML files as 
> java objects with get/set functions, etc. (It's in the  
> org.libvirt.schema package in Daniel Schweger's code)

I'm not convinced that this is a good idea as a formal public API - I'd
keep it as an internal only impl detail for the higher level API you
mention below. 

> Optionally, there could be higher level API that uses the core and XML 
> api, and provides a really clean java-style object model, but IO haven't 
> given it much thought yet.

As an example - the capabilities XML format provides metadata indicating
what values are allowed for the current hypervisor in the domain XML. A
high level API could use this information to provide an easier to use API
for configuring domains and pre-validating the info. 

> I think these two or three layers should be clearly demarcated, maybe 
> even shipped as separate packages, becuse anything that layers on more 
> functionaity that what the current cvs provides represents  design 
> decisions that are not inherent to libvirt.

I agree that any generated-bean API or higher level API should be part
of a separate distributed package. eg a libvirt-java-beans tar.gz to
make it clear that its a higher level API. From a practical dev POV it 
also makes sens because there's no need to couple releases of the higher
level API to the underlying libvirt releases / numbering scheme.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|