Re: BerkeleyDB backend requirements

[Havoc Pennington <hp redhat com>]

Colm Smyth <Colm Smyth ireland sun com> writes:
> 
> I have almost completed implementing the functionality of the
> BerkeleyDB (or "bdb") backend.

Excellent news!

>  The main omissions are
> transactions and locking; some additional error-checking
> is required to bring it up to "production code standards".
>

Since gconfd isn't multithreaded yet and there's no transaction
interface for the backends yet, I guess I can forgive you. ;-)
 
> For rapid access, I store locale values with a modified key, e.g. the
> Spanish locale data for a key /gnome/desktop/logo is 
> /gnome/desktop/%locale%es/logo. This is transparent to
> client code as the gconf_all_dirs() API does not return
> the %locale%es directory in /gnome/desktop and the
> backend API's query_value and all_entries will check the
> relevant %locale% sub-directories for each locale passed.
> 
> My concern is that a schema may specify a locale. If it does,
> I would like to store the applyto-key with the locale
> name-mangling; to do this, I need to be sure that the
> schema has been stored before the schema is associated
> with a key; if it is, then I can get the locale from
> the schema and mangle the key appropriately.
>

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)

 - user-visible portions of the schemas (description, etc.) do 
   need to be stored with translations, since we have to ship that
   text

 - therefore at a given key, multiple schemas (one per locale) can be
   stored

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

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

> By the way, I have an uncertain feeling about the fact
> that the backend interface accesses schema information
> directly. This means that the schema has to duplicated
> over each backend database.
> 

Your uncertain feeling is likely justified. So anytime we are getting
the schema for a key the following needs to be happening:

 a) we search the whole database path for the schema name applied
   to the key, until we find a name

 b) we search the whole database path for the schema itself, returning
    the best translation of the schema (the one nearest to the 
    top of the locale list the user specified)

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

Is this happening correctly in practice? Or were you referring to a
different problem? (Maybe point me at the specific XML backend code in
question, then I'll know what you mean.)

Havoc