Re: Unicode version and libidna

[Simon Josefsson]

Bruno Haible <address@hidden> writes:

>> 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.

That is great.

>> > 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).

I'll consider this.

>> 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.

With the caveat that my implementation isn't finished, and I may realize
better ways to do this, but if the RFC 5892 tables are generated
dynamically from the Unicode properties, it will take significant time.
Generating the property on a character-by-character basis would work,
but without caching of results that may be too inefficient.  Right now
I'm hard coding the 5892 tables, because Unicode versions change
relatively infrequently, but I'm less certain that is the right approach
in the long term.  A system daemon could generate the entire table and
then convert strings quickly.  A compromise may be to generate the
tables during build time, and hard code a check against libunistring
version.  If the libunistring library is upgraded, you would have to
rebuild libidna too.

/Simon