Welcome to the LDAP C API mini wiki at Scratchpad!
You can use the box below to create new pages for this mini-wiki. Make sure you type [[Category:LDAP C API]] on the page before you save it to make it part of the LDAP C API wiki (preload can be enabled to automate this task, by clicking this link and saving that page. Afterwards, you may need to purge this page, if you still see this message).
This page is for documenting flaws in the design of the current LDAP C API and collecting ideas for a new API specification. All LDAP SDK and application developers are invited to contribute comments and ideas.
The initial lists here came from discussions on the OpenLDAP Developers list http://www.openldap.org/lists/openldap-devel/200312/msg00123.html http://www.openldap.org/lists/openldap-devel/200312/msg00187.html
Some of the desired features have subsequently been implemented, but a cleaner interface is still needed.
List of Gripes[]
The list thus far:
- Needs an explicit library_init/library_destroy and a library_handle. (No static/global state, everything referenced by the library_handle.)
- 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.)
- Functions with long parameter lists are difficult to manage. Perhaps use request structures/parameter blocks, like 2.2 slapd.
- Simplified APIs are still desirable, for apps that don't care about controls/extensions/whatever.
- 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.)
- char *'s should be avoided, use struct bervals more extensively
- the API is too malloc-happy. result parsing etc. should be done in-place as much as possible.
- "proper" error handling
- Any routine which can "fail" (e.g., most) should return a clear indication of success or the nature of the failure. ("fail" here refers to API failure, not a protocol failure.)
- Protocol errors are not to be treated as API errors.
- no ld_errno, no ld->ld_errno, etc.. (This relates to Howard's #3.)
- API designed for thread-free implementation
- Ability to provide filters in native (LBER) form
- Applications provided extensibility where ever the ASN.1 allows it
- Applications allowed to "register" new error codes, etc..
- ldap_* be a low-level LDAP API (one-to-one mapping of API to protocol). Higher level "directory" API provided above to handle referral chasing and such.
- Need a way to interact with external event loops - let a calling app manage its own events, and invoke LDAP processing on demand
- If possible, make the operations truly async network-wise. This means the ability to plug in external network event libs. This is possible right now, but it might get a more prominent represenation in the API.
Another gripe I noted was that a lot of APIs are poorly named, but that should be an easy one to fix along the way.
Suggestions for New API[]
What namespaces will we use?