Re: Defining STR_TRANSLATION (ITS#600)

[j_sanchez@stl.es]

moorego@em.agr.ca wrote:
> unresolved:
> ldap_t61_to_8859
> 
> I know I have to compile the ldap and lber libraries with an extra switch
> but I cannot figure out where to insert it?
> Any guidance would be appreciated.

You have to define STR_TRANSLATION to anything and define LDAP_CHARSET_8859
to 88591 or something similar.  Or define LDAP_DEFAULT_CHARSET (but I think
is broken).

However, you cannot do it from configure, your have to do it by hand.
Read libraries/libldap/charset.c.

Anyway, consider STR_TRANSLATION as a deprecated feature is is being
removed from the next OpenLDAP version.  

The concept is broken, charset translation cannot be done at that level.
Some attribute types contain blob values that must not be messed with.
Using ldap_get_values_len to detect that is fragile (you can use that
API function to get string values, IIRC some Perl modules use it 
always).

Charset translation can only be done by looking at the schema and then
doing translation for only those values where it makes sense.  So
either the library has schema knowledge or the application gets
it, either wired in or found at runtime.  The library does not have
schema knowledge, so that leaves it to the application...

Besides, STR_TRANSLATION assumes that you have your data in T.61 and
makes them useable from the (UNIX) command line and simple
clients.  Most LDAP clients out there expect data to be in UTF-8.
So you should be planning transitioning to UTF-8 instead.  Netscape
will be happy, Outlook will be happy, Java will be happy, you can
more or less handle it from Perl, etc.  That leaves your C/C++ programs.
Since you are from Canada, I presume you are interested in ISO-8859-1.
Translation from/to UTF-8 is trivial, you don't need tables.

STR_TRANSLATION is a dead end.  Plan to do without it.

Julio