Random thoughts

[Roozbeh Pournader <roozbeh farsiweb info>]

I was thinking random thoughts about the required subsystem, and we have
lots of questions open:

1) Do we want this as a separate library or a part of, say, glib?

Pros of doing it in GNOME libraries: Much easier adoption, less
dependencies for GNOME applications, help from glib developers in
defining the API etc, more ties to GNOME, less reimplementing the wheel,
sharing bug fixes

Pros of doing it independently: less ties to GNOME which helps adoption
by other platforms and applications

2) Do we want to use glib data types?

Pros of using them: less code, easier to debug, no need to put another
wrapping API over the code to make sure it works for GNOME apps

Pros of not using them: less ties to GNOME which helps adoption by other
platforms and applications

3) Do we want to invent a binary format to store our locale data, like
glibc does?

Cons: harder configurability, more bureaucracy

Pros: faster load times, less need to check input validity, what else?

Examples of modern things using XML config files: fontconfig

4) Do we want to do pure C?

I guess we don't. We could try to do the user application (for
customizing user data) in, say, Python, to test the ground, since that's
allowed in core GNOME applications now. It will help shorten the
development time, while not affecting any applications that use the
data.

5) What are the hard parts?

* Doing it thread-safe, letting the applications get information for
locales different from the one it's running under.

* Taking care of differences in libc and CLDR data. If we want to be
able to get the libc data for other locales than the running one, we
need to be able to read the locale data directly. This would be very
platform-dependent.

* Doing it in real time, so the time format in the clock applet changes
when the user changes the default format.

* Doing the Right Thing for users who login under different locales.
Should we keep their time format setting for the new locale, or did they
only set it for the locale they were using previously?


6) How could we define something that could start to be used by GNOME
applications immediately (not in the 2.12 release of course) and could
be expanded to a usable library progressively?

Politically, I believe we should study what GNOME apps need to know from
locales, and how could we make life easier for both translators and
developers. Starting with visible things is better, the clock applet
coming to mind, which provides both time and data (where we can show
alternate calendars also). But again, applications with developers with
more free time are good, and those with developers who are close with
members here are also good.

Technically, we should try to start small. Small in two ways: code size,
and API size. Since we are starting very late, where lots of libraries
and applications are developed to a good shape, we need to make good
decisions in designing the API, to make sure they won't need to change
it every six months.

7) How do we see the APIs?

I believe we should do them with keeping one eye on what CLDR provides,
and another for what the applications need. Our API should not be like
an XPath to the CLDR data (while it can include a complete wrapper after
a while, it's not necessary at this phase, since it will use the time
that could be used in providing patches to applications who want to use
us). It shouldn't be like the old libc either, which assumes every
question has a fixed and rigid answer (say, we may need to return a list
of string instead of a string in some cases). We should take a look at
the ICU API always, since it's a mature library. We should also look at
what Qt/KDE have.

8) Should we restrict ourselves to what CLDR has?

For the beginning, we should. But after a while, we will need things
that CLDR doesn't have. CLDR has an extension mechanism built-in, so we
can keep to it as the file format.

9) Do we want per-application configuration and a multi-locale desktop?
Like the user being able to use the locale configuration tool to set his
file navigator and clock applet use different data formats?

My answer: While this looks like a nice challenge, let's not think about
it. It's hard even without that.


The ring is yours now,
Roozbeh