[EMAIL PROTECTED] wrote:
> Full_Name: Hallvard B Furuseth
> Version: HEAD
> OS: Linux
> URL:
> Submission from: (NULL) (129.240.6.233)
> Submitted by: hallvard
>
>
> back-relay's be_extended could send a result, but be_extended should
> only set/return it and leave it to the frontend to send it.
> Just fixed by Pierangelo.
>
> Looking at the code, some overlays also send results when used as
> be_extended: pcache:pcache_op_privdb(), retcode, rwm, slapi_overlay.
>
>
> More about back-relay:
>
> - it fails to send anything if the Delete operation is not supported.
>
> - be_abandon, be_chk_referrals and be_operational can return either an
> LDAP result code, or 0 or 1 (which become success and operationError
> if they get used as result codes). I don't know if that matters.
>
> Back-relay operations can be factored out to something like this:
>
> int
> relay_back_op(
> Operation *op,
> SlapReply *rs,
> BackendDB *bd,
> BI_op_func *func,
> Fail_Type fail_mode )
> {
> int rc = fail_mode;
>
> if ( func ) {
> BackendDB *be = op->o_bd;
> slap_callback cb;
>
> relay_back_add_cb( &cb, op );
>
> op->o_bd = bd;
> rc = func( op, rs );
> op->o_bd = be;
>
> if ( op->o_callback == &cb ) {
> op->o_callback = op->o_callback->sc_next;
> }
>
> } else if ( fail_mode > Fail_1 ) {
> rc = rs->sr_err = LDAP_UNWILLING_TO_PERFORM;
> rs->sr_text = "operation not supported within naming context";
> if ( fail_mode == Fail_send ) {
> send_ldap_result( op, rs );
> rc = 1;
> }
> }
>
> return rc;
> }
>
> ...
> return relay_back_op( op, rs, bd, bd->be_bind, Fail_send );
> (void) relay_back_op( op, rs, bd, bd->be_unbind, Fail_0 ); return 0;
> return relay_back_op( op, rs, bd, bd->be_search, Fail_send );
> return relay_back_op( op, rs, bd, bd->be_compare, Fail_send );
> return relay_back_op( op, rs, bd, bd->be_modify, Fail_send );
> return relay_back_op( op, rs, bd, bd->be_modrdn, Fail_send );
> return relay_back_op( op, rs, bd, bd->be_add, Fail_send );
> return relay_back_op( op, rs, bd, bd->be_delete, Fail_send );
> return relay_back_op( op, rs, bd, bd->be_abandon, Fail_1 );
> return relay_back_op( op, rs, bd, bd->be_cancel, Fail_send );
^^^ cancel should __NOT__ send response, since it's an extended
operation. On the contrary, it should set op->o_cancel if it couldn't
relay the operation, otherwise the cancel thread would yield forever.
> return relay_back_op( op, rs, bd, bd->be_extended, Fail_unwilling );
> return relay_back_op( op, rs, bd, bd->be_chk_referrals, Fail_0 );
> return relay_back_op( op, rs, bd, bd->be_operational, Fail_1 );
I like the idea, but that's slightly too simple. The reason I didn't
try to synthesize calls like that was the need to also handle more
complex combinations. For this reason, I'm actually considering the use
of a mask to fine-grain drive the behavior of the helper.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: [EMAIL PROTECTED]
---------------------------------------
