Re: BerkeleyDB backend requirements

[Colm Smyth <Colm Smyth ireland sun com>]

>From: Havoc Pennington <hp redhat com>
>
>Hmm. OK, first let me write down what locales are supposed to be for,
>how I was trying to make it work, etc. just to be sure we're on the
>same page. I have to admit I'm not super-proud of how it works, but I
>didn't have a very much better idea.
>
> - regular values can't actually be translated (they are never 
>   localized, because they aren't supposed to be shipped with the 
>   system, they always come from users)

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.  

> - When assembling a schema value to be returned from query_value(),
>   the most appropriate locale should be chosen (scanning the 
>   locale list, and falling back to "C" locale)

>So I don't think it's right to code the locale in the schema name
>applied to the value, because there are multiple schemas at a given
>key, one per locale, and you don't know which locale the user will
>pass when they ask for the value.

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.

>If that doesn't answer your question, just re-explain, I'm probably
>being dense.

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.

>In the query_value() interface I have a hack to short-circuit this,
>by doing step a) at the same time I'm searching for the value itself.
>But that is simply an efficiency hack and shouldn't affect semantics
>(look at what GConfSources does with the schema_name argument).

Right, this looks safe; even though the backend query_value function
returns the schema, only the first value found is used. This is
good because this way schemas have the same precedence as other keys. 

Colm.