Re: BerkeleyDB backend requirements

[Havoc Pennington <hp redhat com>]

Colm Smyth <Colm Smyth ireland sun com> writes: 
> The man-page description for gconf_get_with_locale() says that right
> now only values of type schema are localized, which implies that
> other information may be localized later.  I assumed this meant all
> value types; I can see benefits in being able to store localized
> regular values as well as localized schemas.

I probably meant "I haven't decided if anything else will be localized
yet." I need to go through all the docs and update them and do
cleanup, that's somewhere on the agenda. I think they are increasingly
out of date.
 
> The mangled names are transparent to applications; they are just
> an artifact of how I store and reference keys for performance reasons.
> 
> I name-mangle both regular keys and keys in the /schemas hierarchy
> to include the locale name, but the application does not use
> the mangled key. An application just asks for /gnome/desktop/logo
> even if there are values stored at /gnome/desktop/%locale%es/logo and
> /gnome/desktop/logo.
>

Right, I thought you were asking about storing the localized schema
name on the key, e.g. if you have /schemas/foo/bar applied to /foo/bar
you were considering storing /schemas/foo/%locale%es/bar on /foo/bar
as its schema name. I don't think that would work. If we localize
values only the value should be localized most likely, not the schema
name and other metainformation.

> 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...)

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.

Havoc