Metadata, icons, ... NLS (was Re: Icons and executable images).

[fpetitje bureauveritas com]

  How to associate metadata to any file while preserving compatibility with
existing filesystem ? This is really a challenge.
  Here, I will deal with executable files ( application or shared library )
only. The additionnal information must be either embedded in the executable
or stored outside of the executable. First solution seems very hard to be
achieved on different Unices and prevent a non privileged user to have a
customized setting (we don't want to have as many applications and
libraries as the number of power users).

  Most modern applications use shared libraries; hence, they are not self
contained. Moreover if appli is internationalized there are as many
appli.cat (or appli.mo) files as there are supported languages. I think
also that the meaning of an icon depends of the reader and of his cultural
background, i.e what an icon looks like should depend of the locale. For
example, a Halloween pumpkin icon doesn't mean much to a chinese, tibetan,
italian or french man (unless he went to local Mac-Donald's :-) )

  So, we ha    ve a separation of a program in two parts : a code part and
a part which depends on the current locale. if localization is deemed
compulsory the developer is pretty sure that all constant strings can be
stuck in the catalog file. ( a fallback mechanism with a POSIC (=C) locale
is to be provided). In fact, he doesn't worry about the availability of the
C library and should not worry about the availibility of appli.[cat/mo] any
more.

  What should go into appli.(cat/mo) ? Naturally, all the i/o formats of
messages which make interaction with the user. In case of a command line
application, this leads to store in the catalog all error messages, input
formats, even the option keywords of the command line. ( "--version" and
the response ). There is a very tight connection between appli and
appli.(cat/mo). In case of an XWindows application, all labels, font names,
resources, ... may be stored in the catalog. With such a trend to store all
the program entities which can be easily represented by strings in the
catalog, the relative importance of said catalog is growing and the size of
executable code may decrease, even resident set size. This is a good thing.
(Icons may be described as xpm strings or encoded as ASCII85 pages 128-129
PostScript Language Reference Manual).

  How can we have and end user customizable application within such a
framework ? (buzzword alert!) A very simple way is this : among all the
messages, a certain number of messages contain user-customizable pieces of
information. They are accordingly documented. The user is given a template
file with a list of customizable strings, filled in with default values and
different possibilities explained and ready to be commented out. If we use
the X_OPEN catgets interface ( gettext() is not available on AIX or IRIX )
we have :
  edit and customize my_appli.msg
  gencat my_appli.cat  my_appli.msg
  appli -C ./my_appli.cat [OtherOptions] [Params]
The call to gencat to "compile" customized settings is at least one order
of magnitude faster than a compile/link pass.
  A number of informations that are known only at install time (or even at
run time) should be stored in appli.(cat/mo) only; and parameters may be
changed later without recompiling/reinstalling the application.

  Pros: fast, flexible, extensible, memory usage
  Cons: number of inodes and open files, installation of messages is
critical.


  As an example, I wrote some times ago an application to compute stability
parameters of a floating body. All the input are handled as commands, these
commands are represented by regular expressions. For a given command there
is at least 1 regular expression, an example of use and hopefully a manual
page (external file). So, you can write :
include loading_case_1.cde
or
lire les commandes dans fichier loading_case_1.cde
and have the referenced file read and its content interpreted. It is highly
flexible as :
(use new) catalog portugese.cat
personnaliser (les commandes de stab)
after these two commands even the regular expressions which define how the
commands are parsed are changed (I suppose that the "personnaliser" variant
was kept in portugese.cat) : that is the program is now understandable at
run time to a portuguese man for instance. The code is very compact (access
to catalog and an editeerr(..) function are in another library); typical
sizes for such an application with 75 commands are
for the executable file  118 747 (AIX)  176 604 (Solaris)
for the catalog                 49 567 (AIX)    53 007 (Solaris) (yes it is
in bytes).
that is : the size of the catalog is a non negligible part of the whole
binary package.


Regards.

PS: I don't know gettext very well and I wonder if following catgets()
stuff can be simulated :
$delset 12
$set 12   regular expressions of commands
$quote "
$
$  FirstNumber Step
5  "10  10"
$
$  unix cde
10 "^!(.*)"
11 "^:!(.*)"
12 "^:!\(.*\)"
13 ""
$
$  help on command
20 "help[ \t]\{1,\}.*command[ \t]\{1,\}([^ \t]*)[ \t]*"
21 ""
$
( I want to read a variable number of strings up to an empty string).

Francois Petitjean