searching multiple backends

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

Perhaps I should look at this new dynamic module support to see if an answer
lies there, but first:

I've encountered a problem which I was all set to tackle, until I realized
there was a more general problem. I have two DSAs, one X.500 and one slapd.
The X.500 server operates over o=bar and the slapd is responsible for
ou=foo,o=bar. I.e., the slapd is subordinate to the X.500 dsa. When the
X.500 dsa receives a DAP request to LIST the entries under o=bar there is no
problem, and the names of everything one level below o=bar is returned. This
request is handled entirely within the X.500 dsa. When it receives an
equivalent LDAP request to SEARCH, scope=ONELEVEL, it enumerates everything
it knows about within its own database, and then chains the request on to
the slapd, with search base o=bar, scope=ONELEVEL. (Yes, our X.500 DSA also
answers LDAP queries, and yes, it's smart enough to use LDAP instead of DSP
when necessary to talk to other DSAs. That's not the point.) The problem is
that the slapd only has a backend configured for ou=foo,o=bar and so is
unwilling to perform a search based at o=bar. This brings me to the more
general problem: suppose I have a slapd configured with multiple backends at
parallel points in the DIT:
	#1 ou=foo,o=bar
	#2 ou=baz,o=bar
	#3 ou=fiz,o=bar

Again, if this slapd receives a SEARCH request based at o=bar, the request
will fail, even though it could/should validly return information for
ONELEVEL or SUBTREE searches from this base. I would expect it to return
information about the base object for all three of these backends, but
currently the do_search function is only capable of invoking a single
backend. 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 think this is something I need; does it
make sense to anyone else?
  -- Howard