Re: Config keyword selection sequence?

[Howard Chu <hyc@symas.com>]

It would probably be a good thing to make the evaluation order go from 
specific to general.

Pierangelo Masarati wrote:
> Slapd's configuration has historically been designed to be quite liberal 
> in what it accepts; global, per-backend and per-database statements 
> could occur almost in any order, with only last-resort consistency 
> checks (e.g. using a database specific keyword before any database 
> definition would have it simply ignored, and only in case handling it 
> would cause harm it would have been considered an error).  Now, 
> configuration is shifting towards back-config, which means it's much 
> more structured, and slapd.conf remains mostly a bootstrap and a 
> transition means to configure the system.  However, I see some 
> inconsistency, or at least some flaw in the way things hare currently 
> handled.  The keyword handling selection needs to consider some cases:
>
> 1) global
> 1.a) global + global overlay(s)
> 2) per-backend (+ global)
> 2.a) (2) + (1.a)
> 3) per-database (+ global); per-backend is prohibited after a database 
> of that type is instantiated, while it's not entirely clear whether a 
> global overlay's configuration needs be handled from inside a database 
> block
> 3.a) per-database + overlay (+ global and so).
>
>
> Maybe someone can be a bit more precise on what the code actually does 
> exactly, but that's essentially the overview.
>
> What happens right now is that:
> A. in case (1) the global keytable is checked (fine);
> A.1. in case (1.a) the global keytable is checked, then that of overlays 
> is checked
> B. in case (2) the global keytable is checked first, then the 
> per-backend table is checked
> B.1. in case (2.a) the global keytable is checked first, then the 
> per-backend table is checked, and finally that of overlays is checked
> C. in case (3) the global keytable is checked first, then per-database 
> keytable is checked
> C.1. in case (3.a) the global keytable is checked first, then 
> per-database keytable is checked, and finally that of overlays is checked
>
> In general, checking goes from general to specific; if it were to go the 
> opposite, things would:
> - be more consistent; in fact, for example, overlays are checked in 
> reverse order with respect to their declaration, so the last overlay's 
> table is checked first; in general, going from spcific to general is the 
> common rule in most of slapd's design (ACL, for example).
> - be more convenient, since databases and overlays could, for example, 
> intercept global directives if they are supposed to have a special 
> meaning to them, handle them as appropriate, and then either 
> short-circuit evaluation, or re-inject them by returning SLAP_CONF_UNKNOWN.
>
> Comments?  Am I overlooking anything essential?


--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/