Re: UTF-8 support for libldap

["Julio Sánchez Fernández" <j_sanchez@stl.es>]

Hallvard B Furuseth wrote:

> If you want one server to handle all the charsets, yes.  That's of
> course more efficient than running 3 servers with the same data in
> different charsets.  But if you just want it to work, and you have some
> disk space and CPU seconds to spare, it should be simpler to have 3
> servers and regularly dump from the master, translate the charset, and
> load into the other servers.  Uhm - provided the clients using the
> non-master charsets do not need write access.

It gets worse than that.  If they try write access, they are supposed to
get a referral to the master server that uses a different encoding for
the protocol...  Well, that's only specified for v3, but it gets pretty
scary...

So that approach only works for read access.  It is a dead end.  If all
options could be made to work on the same server (hey, it could listen
on several ports if no other method can be found), we could still allow
write access.

> No.  Servers need to support "locale-charset-on-wire" if they want to
> support lazy clients that don't bother with charset translation.

Cannot it be done in the library?  What are those clients that
absolutely want latin1 and cannot be re-linked?  So that we understand
better the problem...

Some sites (like yours, I guess) will have to support it for some time,
but clients speaking latin1 (or somesuch) on the wire belong to an
endangered species...

> But your changes don't need to worry about that, since they are on the
> client side.  Besides, I'm sure you support it already.  You do allow us
> to *not* do charset translation in the library, I hope?:-)

I have not tried, but the code is supposed to obey
ldap_enable_translation().  If it worked for T.61, I see no reason for
it not to work with UTF-8.  It's the same code, only that pointers to
different functions are stored in the LDAP struct.

Julio