[Date Prev][Date Next]
Re: redesigning the client API
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.
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.
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).
Need to be able to tie a schema to an LDAP result/operation/etc,
since different parts of the DIT may have different schemas.