From kde-core-devel  Thu Jun 26 10:03:20 2003
From: Thiago Macieira <thiagom () wanadoo ! fr>
Date: Thu, 26 Jun 2003 10:03:20 +0000
To: kde-core-devel
Subject: Re: "International Domain Names" support in KDE
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=105662195526335
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--Boundary-02=_uTs++DsH6Wtmqn8"


--Boundary-02=_uTs++DsH6Wtmqn8
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

Marc Mutz wrote:
>This doesn't make sense. They can just as well link against libidn.
>That's what LGPL is all about, isn't it? And they probably should,
>since it's hopefully going to be the std on Linux until gliibc supports
>it directly.

I wasn't planning to link against the library. I was planning on importing =
the=20
code so that support is present everywhere, regardless of system libraries=
=20
supporting it or not.

>They can't reuse the QString tables, since they are subject to updating
>to Unicode 4.0 eventually. IDNA (nameprep) instead directly references
>the Unicode 3.2 tables and _nothing_ else. Using 3.0 (as Qt currently
>seems to be doing) as well as 4.0 tables would result in
>non-compliance.

That much is true. But that doesn't mean some of the code or data can't be=
=20
reused, if it helps reducing the memory footprint. There's also the=20
converting side of the story: even though both sides are Unicode, Qt=20
currently stores data as UTF-16 while libidn uses UCS-4, which means that w=
e=20
must do Unicode-to-Unicode conversion and then back.

Anyways, this won't be my call. The code I've written for Qt is currently=20
using libidn, but it'll be up to TrollTech to decide if they will use it or=
=20
if they'll integrate their own support -- to match their other platforms.

=2D-=20
  Thiago Macieira  -  Registered Linux user #65028
   thiagom@mail.com          =20
    ICQ UIN: 1967141   PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--Boundary-02=_uTs++DsH6Wtmqn8
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQA++sTuM/XwBW70U1gRAqCXAJ92nm8N+LI+I+DLOIQjpfUZGl9JKQCfTqdh
x9XFaaYWrEWLmPxq4kNiWM8=
=gMRK
-----END PGP SIGNATURE-----

--Boundary-02=_uTs++DsH6Wtmqn8--