[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: backend overlays
Howard Chu wrote:
Pierangelo Masarati wrote:
If this is completely off-topic, please disregard.
Let me try again... The proxycache overlay sits on top of (e.g.)
back-ldap. It also creates an instance of back-bdb for its local
storage. This instance of back-bdb is totally private to the
proxycache overlay, it is completely invisible to the rest of slapd so
you can't configure anything special on top of it. The first question
in my mind was "would you ever need to put another overlay on top of
this private back-bdb?"
Obviously one way to do so would be to add config mechanisms to
proxycache so that its private database can be explicitly configured.
The other thought that occurred to me was to declare overlays in the
backend-specific config directives. Then whenever a backend of that
type is used, it has these other overlays already included. The
problem of course is that if the overlay needs any suffix-dependent
configuration, there's no way to automate that.
I see another problem: in this case, all instances of that backend would
get that certain stack of overlays, which might be undesirable. I'd
consider providing a mechanism (e.g. a sort of generalization of
backover.c) that allows those overlays that use internal databases and
are willing to allow overlay stacking to inject a slap_overinfo
structure in place of the original BackendInfo; then, something like
proxycache-overlay syncprov
proxycache-syncprov-sessionlog 100
could be used to access the configuration of that overlay. By using a
hierarchical configuration directive pattern we should be able to
propagate this to an arbitrary number of layers. The directives would
look quite odd, but at least we don't need to change the style of the
configuration; of course, nested parentheses would be a big plus:
database ldap
overlay proxycache {
proxycache hdb ...
overlay syncprov {
sessionlog 100
}
}
p.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497