7:47 a.m.
On Mon, Jul 07, 2008 at 01:14:40PM +0200, Tóth István wrote:
Daniel Veillard wrote:
> 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).
>
My thoughts exactly.
Okay seems we agree on the fundamentals :-)
> 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.
>
Absolutely. I've had major problems when I tried to use some Java XML
mapping libraries, because they can only process xsd,
and not the language you use. So having high-quality xsd definitions is
high on my personal wish-list.
Okay
> 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.
>
Well, they certainly wouldn't hurt, but I don't see that as a priority.
Java-only programmers (end users) won't touch the JNI core parts.
They will just install the package, and get on with using it, by adding
the jar
to their devel enviroment, and perhaps the JNI lib file to the command line.
These kind of users don't really care about the java-libvirt build
environment.
okay, so just the Jar availability is sufficient for them, okidoc.
If you want to do something more interesting than renaming the java
classes and methods,
the you have to hit the JNI bindings, and that code is so ugly, that
no-one without some C experience will want to touch it.
Having said that, I think that an ant build file would be the most
useful, as it can be used directly in all major
development enviroments. There is also this maven thing, that seems to
be widely used, but I still haven't figured out
exactly what that is :-)
me either, though there are examples in the Fedora-java packaging pages.
[...]
My current plans for java-libvirt are:
1. Add the storage API: It's really mostly just copy-paste-search
replace but it still takes some work
okay
2. There are some consistency problems with the naming of classes
and
methods. I'd like to revisit the java api, and make some changes in
names, and maybe class structure
Hum, better done early than late. Basically i would prefer to avoid
pushing incompatible changes. what kind of inconsistencies problems ?
3. There are many places where the C part leaks memory, this should
also
be audited/ fixed.
Ah, okay I will have to reread the bindings code then. Not sure how
to track leaks, I doubt valgrind can work with java ...
Number 2 is what worries me, I don't know if it's a good idea
to push
toFedora, when I know I want to make incompatible API changes soon.
yes, which is why I would like to know a bit better :-)
(Or you can just say that you won't accept them, but I'm a
big fan of
clean and consistent APIs, and the current one can be improved)
I believe that I will get around to doing 1. and 2. at least in late
july/early august, It's about a three day job, I just don't have that
three days right now :-(
Maybe if you can expose what you think is wrong i can try to clean things up.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
1:26 p.m.
New subject: [libvirt] libvirt-java
The changes to the API that I think of
- Make VirConnectCredential and VirConnectCredentialType into an inner
class of VirConnectAuth
- and rename them to Credential and CredentialType
This gets rids of an extra top level class and encapsulates all auth
related data to VirConnectAuth.
- Remove the "vir" prefix from most method names, and inner classes i.e:
VirConnect.virNodeInfo() would become VirConnect.nodeInfo() and
VirConnect.virNetworkLookupByName would become
VirConnect.networkLookupByName
Basically, I want to get get rid of the "Vir" prefix from all but the
top classes, and the enums.
I might even consider removing the Vir prefix from the top classes (i.e)
VirConnect -> Connect, but I'm not sure about it.
I'd like to know what you think about it.
regards
István
[...]
> My current plans for java-libvirt are:
>
> 1. Add the storage API: It's really mostly just copy-paste-search
> replace but it still takes some work
>
okay
> 2. There are some consistency problems with the naming of classes and
> methods. I'd like to revisit the java api, and make some changes in
> names, and maybe class structure
>
Hum, better done early than late. Basically i would prefer to avoid
pushing incompatible changes. what kind of inconsistencies problems ?
> 3. There are many places where the C part leaks memory, this should also
> be audited/ fixed.
>
Ah, okay I will have to reread the bindings code then. Not sure how
to track leaks, I doubt valgrind can work with java ...
> Number 2 is what worries me, I don't know if it's a good idea to push
> toFedora, when I know I want to make incompatible API changes soon.
>
yes, which is why I would like to know a bit better :-)
> (Or you can just say that you won't accept them, but I'm a big fan of
> clean and consistent APIs, and the current one can be improved)
> I believe that I will get around to doing 1. and 2. at least in late
> july/early august, It's about a three day job, I just don't have that
> three days right now :-(
>
Maybe if you can expose what you think is wrong i can try to clean things up.
Daniel
2:59 a.m.
New subject: [libvirt] libvirt-java
On Mon, Jul 07, 2008 at 08:26:53PM +0200, Toth Istvan wrote:
- Remove the "vir" prefix from most method names, and inner
classes i.e:
VirConnect.virNodeInfo() would become VirConnect.nodeInfo() and
VirConnect.virNetworkLookupByName would become
VirConnect.networkLookupByName
Basically, I want to get get rid of the "Vir" prefix from all but the
top classes, and the enums.
I might even consider removing the Vir prefix from the top classes (i.e)
VirConnect -> Connect, but I'm not sure about it.
I'd remove the vir prefix from everything. We use the prefix in the C
world as our namespace. In Java namespaces are already handled by the
package name org.libvirt so there is no need for a vir prefix. Note
that the Python and Perl bindings also remove the vir prefix so there
is precedent here.
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 :|
9:05 a.m.
New subject: [libvirt] libvirt-java
On Mon, Jul 07, 2008 at 08:26:53PM +0200, Toth Istvan wrote:
The changes to the API that I think of
- Make VirConnectCredential and VirConnectCredentialType into an inner
class of VirConnectAuth
- and rename them to Credential and CredentialType
Okay, I have tried to look at this I ended up with the enclosed patch.
I had a couple of assumptions to do:
- CredentialType would still be a subtype of Credential
- adressing from the GetMethodID() and FindClass() would need
org/libvirt/VirConnectAuth$Credential instead of
org/libvirt/VirConnectCredential and
org/libvirt/VirConnectAuth$Credential$CredentialType instead of
org/libvirt/VirConnectCredential$VirConnectCredentialType
i.e. two $ lookups
This gets rids of an extra top level class and encapsulates all auth
related data to VirConnectAuth.
yeah that sounds fine to me hopefully patched accordinly this still works
- Remove the "vir" prefix from most method names, and inner
classes i.e:
VirConnect.virNodeInfo() would become VirConnect.nodeInfo() and
VirConnect.virNetworkLookupByName would become
VirConnect.networkLookupByName
Basically, I want to get get rid of the "Vir" prefix from all but the
top classes, and the enums.
I might even consider removing the Vir prefix from the top classes (i.e)
VirConnect -> Connect, but I'm not sure about it.
yeah, I think we can get rid of the Vir prefix for everything, except the
enums, where it's probably better to keep them. This mimics what have been
done in other bindings too.
I would come up with a patch too easilly but I first want an initial review
on the Credential refactoring if this looks good I will first commit that one
and then as a second step provide a Vir elimination patch (which will be big
since everything will be modified)
Once that done, after a bit of testing I guess I will make a 0.2.0 release
and push that one to Fedora, sounds right ?
thanks,
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
6014
days inactive
6016
days old
3 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Toth Istvan