Re: redesigning the client API

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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.
  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:
  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):

  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).

- 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.

-- 
Hallvard