"ldap://ldap.company.net/dc=company, dc=net"
-It could do some rewriting to map everything that comes in with a base dn
+It could do some rewriting to map everything that comes in with a base DN
of "o=Branch 1, dc=company, dc=net" as the URI of the Branch 1, and
-everything that comes in with a base dn of "o=Branch 2, dc=company, dc=net"
-as the URI of Branch 2, and by rewriting all the dns back to the new, uniform
-base. Everything that comes in with a base dn of "dc=company, dc=net" should
+everything that comes in with a base DN of "o=Branch 2, dc=company, dc=net"
+as the URI of Branch 2, and by rewriting all the DNs back to the new, uniform
+base. Everything that comes in with a base DN of "dc=company, dc=net" should
be handled locally and propagated to the two branch URIs if a subtree
(or at least onelevel) search is required.
The input of each operation may be related to:
- exact dn exact parent ancestor
+ exact DN exact parent ancestor
-------------------------------------------------------------
bind x
unbind
delete x
abandon
-The backend must rely on a dn fetching mechanism. Each operation requires
+The backend must rely on a DN fetching mechanism. Each operation requires
to determine as early as possible which URI will be able to satisfy it.
Apart from searches, which by definition are usually allowed to return
multiple results, and apart from unbind and abandon, which do not return any
result, all the remaining operations require the related entry to be unique.
-A major problem isposed by the uniqueness of the dns. As far as the suffixes
-are masqueraded by a common suffix, tyhe dns are no longer guaranteed to be
+A major problem isposed by the uniqueness of the DNs. As far as the suffixes
+are masqueraded by a common suffix, the DNs are no longer guaranteed to be
unique. This backend relies on the assumption that the uniqueness of the
-dns is guaranteed.
+DNs is guaranteed.
-Two layers of depth in dn fetching are envisaged.
+Two layers of depth in DN fetching are envisaged.
The first layer is provided by a backend-side cache made of previously
-retrieved entries. The cache relates each rdn (i.e. the dn apart from the
+retrieved entries. The cache relates each RDN (i.e. the DN apart from the
common suffix) to the pool of URIs that are expected to contain a subset
of its children.
the exaustive search of all the URIs unless some hint mechanism is provided
to the backend (e.g. a server is read-only).
-Again, the lag between the fetching of the required dn and the actual
+Again, the lag between the fetching of the required DN and the actual
read/write may result in a failure; however, this applies to any LDAP
operation AFAIK.
- bind
if updates are to be strictly honored, a bind operation is performed against
each URI; otherwise, it is performed against the URIs resulting from a
-cache-level dn fetch.
+cache-level DN fetch.
- unbind
nothing to say; all the open handles related to the connection are reset.
if updates are to be strictly honored, a search operation is performed agaist
each URI. Note that this needs be performed also when the backend suffix
is used as base. In case the base is stricter, the URI pool may be restricted
-by performing a cache dn fetch of the base first.
+by performing a cache DN fetch of the base first.
- compare
-the same applies to the compare dn.
+the same applies to the compare DN.
- add
-this operation is delicate. Unless the dn up to the top-level part excluded
+this operation is delicate. Unless the DN up to the top-level part excluded
can be uniquely associated to a URI, and unless its uniqueness can be trusted,
no add operation should be allowed.
projects / openldap / blobdiff