Re: Unicode version and libidna

[Bruno Haible]

> Once I have established a good set of self tests, I will run them both
> against libunistring for 5.0.0 and 5.2.0 to see if I can find any string
> that behaves differently.

I've now pushed an update to Unicode 6.0.0 as well. So, by choosing the
appropriate gnulib commit when you run ./autogen.sh in the libunistring
checkout, you can test against any of the Unicode versions 5.1.0, 5.2.0,
6.0.0.

> > How will this work with the glibc add-on? Will it incorporate some parts
> > of libunistring literally, or will it load libunistring dynamically?
> 
> I have no idea yet.  Right now, libidna doesn't even link to
> libunistring dynamically because I want to make sure I get the "right"
> libunistring implementation.

You can dynamically load it (with dlopen()), then get a pointer to the
variable '_libunistring_version', fetch its value, and compare it with
your expectations.

Or you can use parts of libunistring as gnulib modules, with module
'libunistring-optional', and your library will be compiled to use a
maximum of the preinstalled library (still considering version requirements).

> Given the complexities in IDNA2008 I am wondering whether it might not
> make more sense to let glibc ask a system daemon to do the string
> conversion rather than to do everything in glibc.  There is still a lot
> of work being done on various pre- and post- IDNA2008 mappings because
> IDNA2008 by itself is neither backwards/forwards compatible or safe to
> use.  This may be something you want to configure on a per-system basis.

Why would you need a system daemon when you need a configuration file?
You need a daemon if different processes need to communicate or if
the configuration is so huge that it should be parsed only once.
For example, the 'pam' facility comes as a set of plugins dynamically
loaded by glibc; they have a set of configuration files; but no daemon
is needed.

Bruno