[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Run-time registered controls
- To: openldap-devel@OpenLDAP.org
- Subject: Run-time registered controls
- From: "Pierangelo Masarati" <ando@sys-net.it>
- Date: Tue, 25 Jan 2005 12:17:47 +0100 (CET)
- Domainkey-signature: a=rsa-sha1; s=mail; d=sys-net.it; c=simple; q=dns; b=M3mK505bsQoLoWbMsilRDR1DMoyzPtOM3EmXu1CTjIro3MXvO6LSgh0k0Xgn2PCCQ ToT2QFmigI9i3CMuCsQYg==
- Importance: Normal
- User-agent: SquirrelMail/1.4.3a-1
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