[cp-patches] RFC: GConf preference api backend
neugens at limasoftware.net
Tue Jun 20 18:29:04 UTC 2006
Il giorno lun, 19/06/2006 alle 07.50 -0600, Tom Tromey ha scritto:
> Mario> This problem is gconf related, and there is at least one bug entry in
> Mario> the gnome bugzilla:
> I'm curious about this.
> What is the failure mode that an application will see if it tries to
> use a bad key? Is there a failure mode we'll see when GConf is
Sorry for the delay, I'm a bit in troubles and will in the next couple
of days :(...
Actually nothing. I think false should be returned, like the specs says,
I'm working on it and it will be likely on the next update.
> My concern is that if we end up having to work around this on the
> Classpath side, then we'll have to implement some kind of name munging
> scheme -- breaking existing classpath-created GConf databases.
I agree, but I think that the best would be to let GConf handle it for
us. This really depends on how much code would break this way.
> I suppose we could add a version number to the internally-added path
Mmmm... this could be a solution.
Ok, so we have two solutions:
1. Mess key names and restore them later
2. Don't accept invalid gconf key names
The first does not work when using two different applications accessing
the same key (how likely it is? More over, is this a real issue?
Application that run on linux/hurd/bsd/<what else> and use gconf have to
face the gconf limitation anyway), the second does not work when the
java application uses an invalid key...
What are the valid characters for keys in the windows registry?
We should check how much of these keys are invalid in GConf, if they are
only few, we could ask the GConf mantainers to add them, if this does
not breaks things in GConf.
If it breaks things, we have to workaround.
> Mario> http://bugzilla.gnome.org/show_bug.cgi?id=161209
> It might be handy to have a 'classpath tracking PR' that depends on
> all the gnome bugs that affect classpath.
Yes, this is a great idea.
> Mario> user root: /apps/java
> Maybe should be /apps/classpath?
This is the same old problem. I think that gconf is a valid backend not
only for classpath.
The preference api is too much windows oriented, but still can be used
with databases of all kinds.
Using a root of "/apps/java" makes it clear we are storing java things
there, if Sun implements a GConf based backend (or if someone likes my
standalone plugin :) they likely will use this name (apps is standard
for application in GConf, java is actually the name of the application,
all java application are registered as java, isn't it?).
Other than that, I have no objections against it, so changing this name
is ok for me.
Lima Software, SO.PR.IND. s.r.l.
pgp key: http://subkeys.pgp.net/
Please, support open standards:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio
Url : http://developer.classpath.org/pipermail/classpath-patches/attachments/20060620/cfcbf03c/attachment.pgp
More information about the Classpath-patches