[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openldap-devel
Subject:    Re: redesigning the client API
From:       Howard Chu <hyc () symas ! com>
Date:       2004-12-02 17:58:08
Message-ID: 41AF57B0.6060904 () symas ! com
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]