On Fri, Jul 04, 2008 at 09:23:36PM +0200, Tóth István wrote:
> I took at a look at that code.
>
> The JNI code is basically unchanged from the 0.1 version.
okay
> The interesting part is the code is for handling the XML structures used
> by libvirt.
>
> 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)
Okay so far i agree.
> 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)
>
> 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.
>
> 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.
> One may not want to use the XML technology/object model/whatever that
> libvirt-java ships, but rather add their own XML handling stuff/ higher
> level abstractions on top of the core libvirt bindings. (for example,
> Daniel Schweger's code uses XMLBeans, my original idea was to use JAXB
> for the same purpose).
Ah, okay.... Well my perspective is that libvirt-java should include
only parts which are directly releated to using libvirt on Java. I would
really not try to reinvent or push any XML related APIs there, at least
as part of libvirt bindings (I still have the scars from libxml2, believe
me you don't want to push new XML APIs to programmers even specialized ones).
But things like the XSD descriptiond might be useful generally, and
IMHO are very tied to libvirt, so i think they are a good fit.
the fact that there may be multiple environment to work on the XML files
means to me that it's better left off, or maybe provided as a contribution on
libvirt.org FTP site, but probably better not integrated, because different
users are likely to do things differently.
IMHO the key point of libvirt-java is to make sufficient bindings to allow
Java developpers to integrate libvirt without pain, while trying to not force
them into a specific model (at least not beyond what libvirt itself imposes).
Also fitting into this model are build makefiles for other environment,
I understand that for most Java developpers, configure and make are really
foreign tools, so adding ant/Eclipse/... build recipes for the package also
makes a lot of sense.
What do you think ?
> BTW I am working on adding the core bindings for the storage stuff, but
> don't expect anything soon, as my day job is currently eating all my time.
Okay, cool. BTW libvirt-java review for Fedora seems done now,
https://bugzilla.redhat.com/show_bug.cgi?id=453119
so hopefully i should be able to push it to more people real soon now.
I also got Solaris portability feedback from John Levon which I need to
integrate, there is clearly some work left, but there is no rush :-)
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list