Re: Syncrepl and chain Overlay

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

Pierangelo Masarati wrote:

> That's correct; in fact, the overlay is called (actually, is stacked 
> on the callback sequence) only if execution gets to the be_<write>() 
> call, which doesn't occurr if the DSA shadows that portion of the 
> naming context.  In this case, the global overlay approach would be 
> the best, but I need to check it out.  For instance, in case of adds, 
> callbacks likely don't get to see the entry at all, or if they do, it 
> diddn't undergo all the massaging provided by slap_mods_opattrs() 
> (which may be a good thing), and it doesn't make it to 
> slap_mods2entry().  In this sense, I'm considering the opportunity to 
> anticipate as much as possible of this massaging __before__ calling 
> the global database operation hook (which can be intercepted by 
> overlays) at the cost of wasting few cycles if the DSA ends up being a 
> shadow.  Maybe we can even move the updateDN and so stuff to an 
> overlay, to be stacked onto shadow databases :)

I'm about to commit a change that allows global overlays to handle 
writes (at least, modifies); for adds, I've currently added a hack in 
the chain overlay, but I expect to remove it quite soon.  My main 
concerns are: some of the check/mod preparation is done way before it's 
sure it's required; for instance, if writing to a replica, the 
modifications are prepared way before finding out that they cannot be 
applied by a regular user.  This is wasting a few cycles, but I think it 
should be acceptable.  The other concern is that now SLAPI is being 
called __after__ these checks/preparation, not before.  This doesn't 
break the idea of SLAPI, but might break existing modules that work on 
stuff __before__ it's checked/prepared.  For instance, a SLAPI module 
that intercepts attributeTypes that comply with the protocol (otherwise 
they don't pass the ber decoding) but are not defined in schema, mapping 
them to existing ones would break, because now the schema enforcement 
occurs before SLAPI.  For this reason, I think we should anticipate 
SLAPI as well.

p.





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