As of May 2015[update], the OpenLDAP project has four core team members: Howard Chu (chief architect),[7] Quanah Gibson-Mount, Hallvard Furuseth, and Kurt Zeilenga.
There are numerous other important and active contributors including Ondrej Kuznik, Luke Howard, Ryan Tandy, and Gavin Henry.
This split design was a feature of the original University of Michigan code written in 1996[10] and carried on in all subsequent OpenLDAP releases.
The standard backends are loosely organized into three different categories: Some backends available in older OpenLDAP releases have been retired from use, most notably back-ldbm which was inherited from the original UMich code, and back-tcl which was similar to back-perl and back-shell.
In practice, backends like -perl and -sock allow interfacing to any arbitrary programming language, thus providing limitless capabilities for customization and expansion.
In effect the slapd server becomes an RPC engine with a compact, well-defined and ubiquitous API.
Ordinarily an LDAP request is received by the frontend, decoded, and then passed to a backend for processing.
Overlays have complete access to the slapd internal APIs, and so can invoke anything the frontend or other backends could perform.
In addition, slapd supports dynamic modules for implementing new LDAP syntaxes, matching rules, controls, and extended operations, as well as for implementing custom access control mechanisms and password hashing mechanisms.
In the OpenLDAP implementation of the RFC 4533, this cookie includes the latest CSN that has been received from the provider (called the contextCSN).
The provider then returns as search results (or, see optimization below, sync info replies) the present (unchanged entry only used in the present phase of the refresh stage) (no attributes), added, modified (represented in the refresh phase as an add with all current attributes), or deleted (no attributes) entries to put the consumer into a synchronized state based on what is known via their cookie.
If the cookie is absent or indicates that the consumer is totally out of sync, then the provider will, in the refresh stage, send an add for each entry it has.
In the ideal case, the refresh stage of the response contains only a delete phase with just a small set of adds (including those that represent the current result of modifies) and deletes that have occurred since the time the consumer last synchronized with the provider.
However, due to limited session log state (also non-persistent) kept in the provider, a present phase may be required, particularly including the presentation of all unchanged entries as a means (inefficient) of implying what has been deleted in the provider since the consumer last synchronized.