Re: redesigning the client API

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 07:24 AM 12/2/2004, 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:

The LDAP decoders would also not require use of sockbuf.  One
could simply hand them a pointer to a buffer holding some
octets.

>>>  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.

The application, not the library, knows which values it wants
transliterated and how, it is best able call the transliteration
function(s) as needed.  Defining an API which the application
can use to tell the library when to call the transliteration
function(s) does not add value and certainly never will cover
all application needs.

>> In fact, I am leery of the
>> library providing distributed directory support.
>
>Hm?  Then how will referrals be handled?

(I was just noting here that I am leery of providing automated
facilities as client developers will likely not think before
using them.)  They would be handled in the high-level directory
API I envisioned.

>>>- 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.

I guess I am not sure what you want the library to do for you.

To me, the LDAP encode/decode API should be dumb.  It should just
encode and decode PDUs.  The Directory API should be a bit smarter.
It should have some distributed directory support.

Kurt