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


> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga

> Of course, maybe we should just give up on trying to "fix" this
> library and just write a new one...  I've been quite close to
> doing this before (I've actually started doing it a few times),
> but it's more work than I want to take on right now.

We need to make this happen... Maybe we can just start by describing how a
new API should be structured in general terms, in contrast to the present
API. After we get enough ideas collected together we'll all have a better
idea of where to go next. Some points I have in mind:

1) Needs an explicit library_init/library_destroy and a library_handle. (No
static/global state, everything referenced by the library_handle.)

2) APIs for operations must have a function parameter for every operation
protocol parameter. (E.g., current ldap_search variations all omit DEREF, so
you can only specify this via ldap_set_option. Ugly.)
  2a) Functions with long parameter lists are difficult to manage. Perhaps
use request structures/parameter blocks, like 2.2 slapd.
  2b) Caller must provide storage for pointers-to-results. (E.g., no
mallocing struct bervals to return a berval to caller.)

3) Requests and results must be bound together. (E.g., ldap_get_option(
OPT_ERROR_NUMBER) has no notion of which result's error is being retrieved.)


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