Re: data types and inheritance
- From: Bruno Haible <bruno clisp org>
- To: Roozbeh Pournader <roozbeh farsiweb info>
- Cc: GNOME Locale mailing list <locale-list gnome org>
- Subject: Re: data types and inheritance
- Date: Wed, 17 Aug 2005 22:58:56 +0200
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
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?
] [Thread Prev