[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: LDAP_DEPRECATED in OPENLDAP_REL_ENG_2_2
> -----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