[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: redesigning the client API

Hallvard B Furuseth wrote:

Kurt D. Zeilenga writes:


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.



I don't see how that makes any difference, if one must still call the
library to check if there is a new LDAP response available.  To wait for
e.g. next <LDAP response or input to some other socket>, one needs to
select() on something, so one needs to know which file descriptors to
select() on.  Thus:



If you rephrase this expectation a bit, I could agree with it. Since there may be multiple communication layers involved (e.g. TLS and/or SASL security layer), getting a positive indication from select() only means there is *something* available, not necessarily a (complete) LDAP response.

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.




--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support