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