Re: redesigning the client API

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

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