Re: BerkeleyDB backend requirements

[Colm Smyth <Colm Smyth ireland sun com>]

Two more points related to this:

1. Naturally to fully support localized values, some other
APIs are required:

- gconf_set_with_locale() 
- gconf_unset_with_locale()

There is an unset_value() backend function that takes a locale path value,
but set_value does not take a locale.

2. I don't see an obvious way to disassociate a schema from a key;
   the gconf client-side APIs check that the key is non-NULL and
   non-empty so this is currently not a way to do this.

Colm.

>From: Colm Smyth <colms ireland sun com>
>Subject: Re: BerkeleyDB backend requirements
>To: hp redhat com
>Cc: gconf-list gnome org
>Mime-Version: 1.0
>Content-MD5: ZZJ8gqZRaSD8D+cHbDGCZQ==
>
>>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.

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