[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: redesigning the client API
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:
>> 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.
>>- 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.
Well, I meant for applications to set callback functions which would do
transliterations. How much support the library would provide for that
(iconv interface etc.) I don't know.
You said you didn't like callbacks last time, but when I played with it
I still couldn't come up with a non-callback interface which wouldn't
require the user to name or call a conversion function for every
attribute.
> In fact, I am leery of the
> library providing distributed directory support.
Hm? Then how will referrals be handled?
>>- 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.
Might be enough to provide some hooks for it -
i.e. s/schema/user-provided info/ for now.
I just suspect that when we someday get support for multi-schema in
OpenLDAP, we'll need a library which can support it. It would be a pity
to have to design yet another library because this library lacks the
necessary parameters in some library calls, or whatever.
--
Hallvard