hyc@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/back-sock
Modified Files: config.c 1.11 -> 1.12
Log Message: As an overlay, always return SLAP_CB_CONTINUE
Alternatively, we can use the actual return code from the external program, and document that those programs should return SLAP_CB_CONTINUE if they don't want to override the normal flow of processing. Thoughts?
We could write a similar wrapper for back-perl, but a few other loose ends need to be addressed there still. First, this business of arbitrary junk in slapd.conf being fed into the perl module - I suggest this be replaced by an actual "perlconfig" directive whose arguments are passed on. Then we can convert all of that to cn=config without any further mess.
hyc@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/back-sock
Modified Files: config.c 1.11 -> 1.12
Log Message: As an overlay, always return SLAP_CB_CONTINUE
Alternatively, we can use the actual return code from the external program, and document that those programs should return SLAP_CB_CONTINUE if they don't want to override the normal flow of processing. Thoughts?
I favor this second option: if one uses back-sock (back-perl) he needs to know what he's doing, so carefully reading the documentation is mandatory.
p.
We could write a similar wrapper for back-perl, but a few other loose ends need to be addressed there still. First, this business of arbitrary junk in slapd.conf being fed into the perl module - I suggest this be replaced by an actual "perlconfig" directive whose arguments are passed on. Then we can convert all of that to cn=config without any further mess.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
masarati@aero.polimi.it wrote:
hyc@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/back-sock
Modified Files: config.c 1.11 -> 1.12
Log Message: As an overlay, always return SLAP_CB_CONTINUE
Alternatively, we can use the actual return code from the external program, and document that those programs should return SLAP_CB_CONTINUE if they don't want to override the normal flow of processing. Thoughts?
I favor this second option: if one uses back-sock (back-perl) he needs to know what he's doing, so carefully reading the documentation is mandatory.
OK, will get to that shortly.
Also want to add some more config options: 1) select which operation types to trigger on 2) select whether to forward search entry responses 3) select whether to forward result messages at all
Probably tweak the protocol a bit more, just return a "CONTINUE" message instead of a "RESULT" message for SLAP_CB_CONTINUE.
The overlay may need to send a CLEANUP message if the request was forwarded but processing fell into the cleanup handlers instead of the response handlers.
p.
We could write a similar wrapper for back-perl, but a few other loose ends need to be addressed there still. First, this business of arbitrary junk in slapd.conf being fed into the perl module - I suggest this be replaced by an actual "perlconfig" directive whose arguments are passed on. Then we can convert all of that to cn=config without any further mess.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Howard Chu wrote:
masarati@aero.polimi.it wrote:
hyc@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/back-sock
Modified Files: config.c 1.11 -> 1.12
Log Message: As an overlay, always return SLAP_CB_CONTINUE
Alternatively, we can use the actual return code from the external program, and document that those programs should return SLAP_CB_CONTINUE if they don't want to override the normal flow of processing. Thoughts?
I favor this second option: if one uses back-sock (back-perl) he needs to know what he's doing, so carefully reading the documentation is mandatory.
OK, will get to that shortly.
Also want to add some more config options: 1) select which operation types to trigger on 2) select whether to forward search entry responses 3) select whether to forward result messages at all
Probably tweak the protocol a bit more, just return a "CONTINUE" message instead of a "RESULT" message for SLAP_CB_CONTINUE.
The overlay may need to send a CLEANUP message if the request was forwarded but processing fell into the cleanup handlers instead of the response handlers.
For use as a simple trigger, probably the only thing that's needed is a hook in the response handler that forwards a single message containing the original request parameters and its result code, rather than sending the request as-is, and then the result in a separate message.
p.
We could write a similar wrapper for back-perl, but a few other loose ends need to be addressed there still. First, this business of arbitrary junk in slapd.conf being fed into the perl module - I suggest this be replaced by an actual "perlconfig" directive whose arguments are passed on. Then we can convert all of that to cn=config without any further mess.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
-
Howard Chu -
masaratiļ¼ aero.polimi.it