[Date Prev][Date Next]
RE: New Proxy cache overlay
> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> One of the problems I see with both of these approaches
> is that they don't say which if of the layers applied to
> the source backend are applied before tee'ing to the
> relay/rewrite backend.
> Maybe we need something like:
> database bdb
> overlay post
> overlay relay "o=example,c=us"
> overlay pre
> suffix "dc=example,dc=dc=com"
> database relay
> overlay rewrite
> suffix "o=example,o=com"
> The DN "o=example,c=us" basically names the pipe.
> (Note that slapd.conf(5) should support these backends being
> presented in either order.)
I see what you're getting at, but let's start with something simpler first -
a plain database backend, with nothing else special of its own:
rewriteRule (.*)o=example,c=us %1dc=example,dc=com
The relay database can't do anything useful without the rewrite engine; I
think that bit should just be implicit. For ease of implementation, I'd
rather require that the target database be configured before the relay.
Currently the order of execution is: overlays in the order they were
configured, followed by the underlying database. It might have been more
consistent to execute the overlays in reverse order - last one configured is
the first to run. Then you can visualize this as a stack of layers, starting
from the last/top and going down to the underlying database/bottom. Like so:
and the execution order for a request to the relay context would just run
backwards through the configuration:
overlay 4, 3, relay, overlay 2, 1, bdb
The above has a certain attractiveness. Right now it would go:
overlay 3, 4, relay, overlay 1, 2, bdb
which could get rather confusing.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support