Il giorno dom, 14/05/2006 alle 14.51 +0200, Robert Schuster ha scritto: > Hi, > thanks to Mario a long standing wish to have a GConf-based backend for > java.util.prefs is becoming a reality. > > I think it is quite clear that GNU Classpath wants this code! :)
Hi! I know this is a long email, sorry to the list (and sorry also for my english)... I'm glad to hear you! I wrote this backend because we needed it, and I found that classpath needed it too... I think that contribute it to the community was the right think to do (and if it gets accepted is simply a great thing and an honor for me!). > However there are some questions and things to do: > > 1) Copyright assignment. > Mario and everyone who has worked on the code needs to assign copyright to the > Free Software Foundation before we can integrate it. This is no problem at all, just I need to know how (and what) to do. > 2) Backend chosing > How is should the user or the package maintainers decide which backend is to > be > used? Do we want a configure-time option or provide a possibility to chose the > backend when starting the VM (using a property). Ok, this is a bit tricky. In both gnu classpath[1] and sun jdk the backend is choosen by setting this system property: System.setProperty("java.util.prefs.PreferencesFactory", "gnu.java.util.prefs.GConfBasedFactory"); Assuming the package name for the backend will not change. Anyway, there are few problems, I tried to be more close to the specs as possible, but gconf does not work like the windows registry, and I think that sun had the windows registry in mind when they designed the preference api. There are a couple of problems (I'm still checking for others): * sync does not really sync the backend: is just an hint. From the specs: Sync Ensures that future reads from this preference node and its descendants reflect any changes that were committed to the persistent store (from any VM) prior to the sync invocation. This is not always true, gconf may cache changes, and do not reflect them immediately. Anyway, almost always these changes reflect immediately (and I call gconf_suggest_sync often to reduce this risk). Infact, the gconf database is not updated in sync with the client, but in a given VM, the changes are consistent. So, the statement "(from any VM)" cannot be always satisfied. * The second problem is where to store user and system properties. GConf uses the standard of /apps/appname to store "user node" appname preferences. System preference are stored in /system. The preference api stores them under /package, where package is, for example, /gnu/java/util/prefs/gconf/ This is not allowed by gconf (at least, not recommended), so I used this default: user preference in /apps/java/package and system preference in /system/package This follows the gconf standard, but creates an ugly unbalanced tree under the gconf database. Still, I think is a correct solution, after all, java.util.prefs requires that the preferences are stored under a directory called /package, gconf requires that user preference are stored under /apps/appname. The root /apps/java is not exposed to the java api, so both standards are happy... As a side note, these directory can be configured at runtime by setting one of these two properties: java.util.prefs.gconf.user_root java.util.prefs.gconf.system_root * Finally, it would be fine to integrate an observer for "value_changed" events. Actually, observers only generate an event if the value of a key is updated by java code. Instead, gconf should warn all registered listeners if a key changes no matter how this change is done (for example, an administrator sets a key with the gconf editor). If I have understood how classpath works, this can be enabled when the gtk-peer is also enabled. I'll work on this in the next few days hoping to came with a nice solution. Wow! What a long mail... sorry!! :) > cya > Robert Ciao, Mario [1] it seems that this does not work on the gcj version shipped on fedora, but works on the last classpath with cacao. -- Lima Software, SO.PR.IND. s.r.l. http://www.limasoftware.net/ pgp key: http://subkeys.pgp.net/ Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/
signature.asc
Description: Questa รจ una parte del messaggio firmata digitalmente