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
