RE: searching multiple backends

["Howard Chu" <hyc@highlandsun.com>]

> This is because searches should be confined to one naming context.
> Clients should use namingContext attributes within the root DSE
> to better structure their searches.
>
> >Fixing this would require modifying all of the backend search
> >functions to prevent them from sending a final search result
> code, leaving
> >it to do_search to send instead.
>
> I don't think it's broken, per say, as the specification allows
> our current approach.  However, there are likely other approaches
> worth considering.
>
> Kurt

Let me propose a new approach for consideration:
Currently each backend is treated essentially as an individual DSA - it has
its own naming context separate from all others. This approach really runs
counter to the X.500 notion of a global directory that is fully integrated,
and only propagates the "islands of information" characteristic that
afflicts most current LDAP implementations.

Instead, imagine everything served by a particular DSA all residing within a
single, integrated tree. In this case, "backends" are treated more like
plugins than like entire standalone DSAs. I'm suggesting a rewrite of the
current backend storage/selection code that actually uses the LDBM backend
to store references to the other backends. So instead of an explicit
"select_backend" function, you merely walk down the DSA's DIT in a normal
tree traversal. If you find a regular entry at the end, fine, just send it
back. If you find a "plugin" reference somewhere along the line, you
redirect processing at that point. The configuration language doesn't really
need to change all that much. The processing needs to accomodate the fact
that configuring a backend with suffix o=x,o=y,o=z should implicitly create
o=y,o=z and o=z if they don't already exist. (Remember, the X.500 spec
requires this behavior or some logical equivalent, and the current slapd is
in violation of this spec.)