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