[Date Prev][Date Next] [Chronological] [Thread] [Top]

Run-time registered controls



I'm working at dynamically registering the Chaining Behavior control by
the chain overlay, and I noticed that there seems to be no mechanism to
dynamically register controls in the bi_controls array.  This is necessary
to pass the backend_check_controls() then the criticality flag is set
(also, I note that test should be reworked as per ITS#3308; I'll also look
at that).  By the way, it appears that the syncrepl control, which is the
only other control registered by an overlay I have seen so far, doesn't
provide any means to set the criticality flag to true for the
LDAP_CONTROL_SYNC (the only allowed within <draft-zeilenga-ldup-sync>) at
the consumer's side; is it by design or to circumvent the check?

To keep things simple, I suggest we add a be_controls pointer to the
BackendDB structure, which is initialized with a copy of the bi_controls
array; overlays that provide support for a control, in the bi_db_open()
hook,  should realloc that array and add the OID(s) they support.  I guess
this could be a problem, because they are likely to see a copy of the
BackendDB structure at that point, so a more thorough mechanism (e.g. a
over_provide_control() call that is capable to get to the __real__
BackendDB structure of that database) should be set in place.

Of course, I might be missing a much cleaner and simpler solution, or
overlooking other side effects...

Comments?

p.

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


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