[libvirt] Re: Libvir-list Digest, Vol 32, Issue 7
Daniel P. Berrange
berrange at redhat.com
Mon Jul 7 11:27:46 UTC 2008
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 :|
More information about the libvir-list
mailing list