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 :|