redesigning the client API

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

I've had a number of offline discussions with various
folks regarding the need to redesign/reimplement the
client API.   As frequently noted, the current API
(and its implementation) suffer from a number of
problems, including poor error handling, poor handling
of referrals/search continuations, poor handling of
security contexts (especially in the face of referrals/
search continuations), and I/O issues.  Also, depending
on how distributed operations are specified, we may also
need to re-encode PDUs into the extension value of an
extended operation.  I think a new API is needed (though
hopefully we can borrow some of the existing API's
implementation).

Hence, I am thinking the following general design
might be appropriate to have the following disjoint
APIs:
  1) layered I/O (Sockbuf) API
  2) LBER encoding/decoding API
  3) LDAP encoding/decoding API
  4) LDAP utility API
  4) LDAP session API
	(A LDAP session involves one LDAP connection to
       a particular server.)
  5) Directory session API
       (A Directory session involves possible multiple
	LDAP connections to various servers which are
	subject to some shared security policy statement.)

I note that it would be possible to utilize a 3rd party
layered I/O system, or a 3rd party DER-encoder/BER-decoder.

Of course, the devil is in the details.

Comments?

Kurt