[Date Prev][Date Next]
RE: LDAP schema propagation to the backend
- To: <email@example.com>
- Subject: RE: LDAP schema propagation to the backend
- From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Date: Mon, 31 Jan 2000 16:12:16 -0800
- Cc: "OpenLDAP Development" <openldap-devel@OpenLDAP.org>
- In-reply-to: <NDBBIHELCLJAIOOJICFHOEODCBAA.firstname.lastname@example.org>
- References: <email@example.com>
At 05:21 PM 1/31/00 -0000, Joao Abrantes wrote:
> I think the penalty in performance is so big we should consider defining a
>core syntax and matching rule set (a set that all backends support) and then
>defining extensions to this set per backend.
We want syntaxes and matching rules to independent of database backends
otherwise we lose the schema extensibility which is one of the key benefits
> This way we could optimize queries because the backend has knowledge of the
>core set. This is actually done in other LDAP servers (Netscape per
>example... which defines a core set and then can be extended via a plugin).
This is exactly the direction were moving in. There will be a set of builtin
syntax and matching rule handlers and a mechanism to plugin additional handlers.
Though a database backend could register additional syntax/matching rules, it
is not encouraged. A general database backend, however, should be able deal
with any registered syntax. To facilate this, matching rule handlers include
routines to support indexing. A backend may choose to support such indexing
or not and/or choose to provide their own indexing. Indexing, regardless of
implementation, must produce a set of candidates that does not exclude any
entry that matches the filter.
Frankly, I really don't see DBMS builtin indexing to be of much value...
unless they happen to support indexing of UTF-8 encoded ISO 10646 strings
in a manner consistent with LDAPv3 (X.500) matching rules.