Re: BerkeleyDB backend requirements

[Colm Smyth <Colm Smyth ireland sun com>]

>> No, I think we just are working from different assumptions and so
>> we are interpreting things a little differently. I know there
>> are situations when regular GConf values need to be localized;
>> as an example, what if an application needs to be run from
>> different directories depending on the desired locale; the
>> gnome-mime app bindings would need to be locale-sensitive. 
>> 
>> Clearly we could rely on applications to create locale-aware
>> keys but we can more efficiently check multiple keys in the
>> backend for each active locale.
>>
>
>I'm not sure it's a good idea. For one thing (and this applies to
>schema values at the moment), if we have locales on values it's
>unclear how notification works (you want to notify if the value for
>the locale the app is currently using changes, but you don't know
>which locale the app is currently using, so we'd need to pass in a
>locale with the notification registration I guess, and this
>complicates a bunch of code because to see if a value has changed we
>have to check not only whether it was set but also whether setting it
>ended up affecting the value for a given locale...)

For the callback to be called only when a _relevant_ change occurred requires
GConf to track which locales were passed to each gconf_get_with_locale().  This
requires too much data to be stored.  I would argue that NotifyFunc should pass
the locale value and let the app decide if the update to this locale's value
is significant.

It is also hard to notify when a default value changes; this requires
checking every schema update that adds/updates/removes a default
value. In the BerkeleyDB backend, I have made it efficient to discover
the schema for a given key, but it is hard to find the keys for a given
schema.

>Requires some thought anyway. I'd like to consider more carefully how
>hard it would be for apps to handle this themselves.
> 
>It shouldn't hurt of course to write the backend in a generic way now,
>so that any value can be localized. Maybe that will turn out to be
>correct.

That's what I've done. If it would help in making this decision, I could
compile a list of sample settings that should be locale-sensitive.

Colm.

>Havoc

--
Colm Smyth - Sun Microsystems, Ireland - Desktop S/W Engineering
Sun Xtn: 19166    Phone: 353-1-819-9166   Fax: 353-1-819-9200