Re: what if we move SLAPI to a (global) overlay?

["Pierangelo Masarati" <ando@sys-net.it>]

>
>>Sure.  At present, I'm simply in the stage of checking whether this can
>>be done or not.  As I already pointed out, I had to anticipate part of
>>the consistency checks that are run on writes in slap_mods_check() to
>>provide mods data in a safe state to global overlays.  This causes
>>current SLAPI code to be called __after__ the checks, while it use dto
>>be called __before__.  I suggest you check that this doesn't break
>>existing slapi modules.  I think this is necessary, otherwise we will
>>need to specialize overlays to be used as global rather than database
>>specific.
>
> Changing the order would actually fix a long-standing issue in one
> plugin, but unfortunately it will break plugins that set default values
> for mandatory attributes (and we have several such plugins).
>
> (See the addrdnvalues plugin for an example.)
>
> This behaviour is critical to our application. Is there a way around
> this?

I see.  Actually, this behavior could be interesting for global overlays
as well.  I think the sequence of operations needs to be reconsidered a
bit in general, besides these changes.  Earlier, slap_mods_check() was
doing everything in one row because there was no intermediate layers, but
the only reason to do things in that order was to use a single loop
instead of separate ones.  I think we need to split the loop in several
portions, essentially to:
- anticipate schema mapping, i.e. mods->mrs_desc setting
- defer schema compliance (structuralObjectClass chain assessment,
namingAttributes and distinguishedValues presence, and so)
- further defer shadowing (I intend to move replication checks to a
database-oriented overlay); so the sequence would become:

- frontend: ber decoding
- schema mapping
[optional] - global overlays (including SLAPI)
- schema checking
[optional] - database overlays (including replication)
- backend

Note that HEAD already breaks those modules that rely on SLAPI being
called before slap_mods_check(); I'll fix this shortly by operating this
split.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497