Re: String conversions UTF8 <-> ISO-8859-1

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Hallvard,

Maybe we do disagree on a few things other than which mechanism is
appropriate, but they are mostly moot.

Even our Unicode/UTF-8 discussion is moot.  My basic point was just
that internet protocols and libraries which support them are all moving
towards full Unicode/UTF-8 support and that applications which choose
other charset/encodings for internals are going to have to deal many
conversion issues (aside from user<->internals conversion issues).
The discussion is moot as even applications which choose Unicode/UTF-8
may need to do conversions.  I gave translations as one general
conversion, but there are others (such as applying Unicode normalizations,
case foldings, etc..).

When it comes down to it, I think our disagreement is largely over
the suitability of the API mechanisms.

Personally, I would like to see better "helper" functions provided
to application developers.  Such as routines to parse out the type
and options of an attribute description, or routines which evaluated
assertions such as "is type X" or "is option Y present", or routines
which help applications walk through LDAPMessages (the get/first
routines suck).  I'd also like to see routines that convert messages
to structural representations.  For example, a routine which produced
an LDAPMod from an LDAPMessage containing an entry would be useful.

These kinds of routines would be generally useful, even beyond
value conversion.

Now, I think callbacks have there place in the API design.  I just
think they are well suited to this particular problem.

There are two main issues. 
	1) how to get application context into the callback;
	2) how to get protocol context into the callback.

For 1), we have few choices.  Either we add "void *applctx" arguments
to many functions, (ab)use the session handle (this will be problematic
once we move to operation-level concurrency), or require applications
to use globals (which has severe concurrency issues).

For 2), the problem is how to provide context where the library doesn't
know the protocol structure (such as in controls, extended operations,
SASL credentials, etc.).  These things are just blobs to the library.
So, our only real choice here is to exclude values in such structures
from the callback mechanism.  For examples, considers the proxyAuthzId
control and the WhoAmI? extended operation.

Kurt