Re: data types and inheritance

[Peter Nugent <Peter Nugent Sun COM>]

Hi Roozheh
I assume your question is about user configured locale data like when it
is configured through language and culture capplet. If this is the case
then we should use gconf. It's user centric and changes take effect
immediately in apps using this data without having to restart them,
Windows does the same : it uses the registry

there is no need to have a locale like xx_YY_CUSTOM. The user logs into
xx_YY and the user cconfigured data is picked up. If it's not configured
then the default (CLDR) data is used.

Peter

Bruno Haible ha scritto:
> Roozbeh Pournader wrote:
> 
>>I see only one problem: what should happen for user configuration?
>>
>>I used to assume that a user configuration file should be something that
>>gets added at the end of the "locale chain" as the inheritance is
>>concerned. So, it would work as if the user is running under the the
>>locale "fa_IR_CUSTOM". This may require the whole XML set when one (say,
>>a web application) encounters some small code (which may contain
>>aliases, etc) passed to it from the client application.
>>...
>>But I guess the cooker should also be able to create an expanded XML
>>file (with all inheritance, alises, and default attribute values
>>expanded), something that would result essentially in the same cooked
>>file but without reading any extra file, in case the user wants to pass
>>her whole settings around to someone else, like a web application.
> 
> 
> So far, I've been imagining that the cooker works as follows. Let's see
> whether this is enough for user configuration.
> 
> - The runtime library looks for its mmapable files at one single place
>   in the filesystem. This location can be set through an environment
>   variable ("GLOCDIR"), allowing use cases such as
>     1) A locally modified set of mmapable files under $HOME/.glocale,
>     2) "make check" inside the library itself.
> 
> - The cooker has an in-memory representation of the locale data, plus
>   the following converters:
> 
>      glibc          --> in-memory
>      LDML XML       --> in-memory
>                         in-memory --> mmapable files
>      mmapable files --> in-memory
> 
>   It also needs a "merge" operation that takes two in-memory representations
>   and merges them, giving preference to one or the other. This is certainly
>   needed to create the combination of glibc data and CLDR data, with
>   preference for one or the other.
> 
> The questions that you've raised are:
> 
> 1) Why only a single lookup location, and not several ones ("GLOCPATH")?
>    The answer is: The cooker can do it. It is acceptable if the cooker
>    regenerates the whole set of mmapable files, not just part of it.
>    [OK, _if_ the cooking pass turns out to be too slow at the end, we can
>    introduce GLOCPATH instead of GLOCDIR. It's a modification in two or
>    three files.]
> 
> 2) How to create an expanded XML?
>    Simple: Write an  in-memory --> XML converter.  It's work, sure.
> 
> 3) How to create a minimal differential XML?
>    Like the "merge" phase: takes two in-memory representations as input,
>    and produces a single one as output, possibly with many missing fields.
>    Then the in-memory --> XML converter is applied.
> 
> How does this fit you?
> 
> Bruno
> 
> _______________________________________________
> locale-list mailing list
> locale-list gnome org
> http://mail.gnome.org/mailman/listinfo/locale-list

-- 
Peter Nugent,
Software Engineer,
Sun Microsystems Ireland Ltd,
Hamilton House,
East Point Business Park,
Dublin 3,
Ireland.
Tel +353.1.8199522
Email: peter nugent sun com