Re: redesigning the client API

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

At 02:26 PM 12/1/2004, Hallvard B Furuseth wrote:
>Some other wishes - not sure of what you'd think of as part of one of
>the other APIs, and what you'd think of as a separate API:
>
>- Event loop support:
>  Ability to plug ldap into an event loop, so e.g. incoming LDAP
>  results provide events.

First, the LDAP encoding API would provide access to encoded
PDUs.  The client would not be required to use our sockbuf
library.

>  E.g. via:
>
>- Select():
>  Something like fd_set operators which take LDAP sessions or
>  directory sessions instead of file descriptors, so one can
>  select() and detect possible LDAP activity.
>
>- Maybe asynchronous I/O.
>  Or at least keep the door open for it.  I'm not sure if the
>  synchronous I/O is a problem in practice.
>
>- Threading:

I prefer the libraries to be as thread-free as possible...

Instead of locking, it might be better to provide hooks where
the caller can provide protected versions as needed.  (This
is the approach Netscape took in their LDAP API.)

>  Ability for the user to access mutexes etc which the library uses to
>  protect resources outside the library, and also to make the library
>  use some other mutexes or semaphores (which some other library is
>  using to protects the same resource).
>
>  Not sure if it's possible to get this both right and convenient...
>  we can't know which resources are used by external libraries used by
>  ldap, so there must be some catch-all mutexes anyway.
>
>- Character set conversion (or more generally, parsing, building and
>  conversion of attribute values and other LDAP protocol elements):

Well, we certainly should provide support for SASLprep and LDAPprep
in our utility library.

>  I know the discussion stranded last time, but I still think we need
>  some sort of support for this, in a way which doesn't require the
>  user to call a conversion function every time he gets or puts a
>  value from/to LDAP.
>
>  Would need to be schema-aware (when informed by user).

I rather the LDAP library be dumb.  I rather transliteration
be left to applications to do.  In fact, I am leery of the
library providing distributed directory support.

>- Schema:
>  Need to be able to tie a schema to an LDAP result/operation/etc,
>  since different parts of the DIT may have different schemas.

To do this generally requires significant smarts.  See above.


>-- 
>Hallvard