Re: op->o_private

[Luke Howard <lukeh@padl.com>]

What about exposing the SLAPI operation extension code in slapi/slapi_ext.c?

/*
 * Object extensions
 *
 * We only support two types -- connection and operation extensions.
 * Define more types in slapi.h
 */

/* global state */
struct slapi_registered_extension_set {
        ldap_pvt_thread_mutex_t mutex;
        struct slapi_registered_extension {
                int active;
                int count;
                slapi_extension_constructor_fnptr *constructors;
                slapi_extension_destructor_fnptr *destructors;
        } extensions[SLAPI_X_EXT_MAX];
} registered_extensions;

/* per-object state */
struct slapi_extension_block {
        void **extensions;
};

-- Luke

>From: Howard Chu <hyc@symas.com>
>Subject: op->o_private
>To: OpenLDAP Devel <openldap-devel@OpenLDAP.org>
>Date: Thu, 13 Oct 2005 13:53:19 -0700
>
>Just a minor issue, but I've been thinking op->o_private needs to be 
>managed explicitly so that multiple modules can hang data there without 
>interfering with each other. E.g.
>    typedef struct TaggedList {
>       struct TaggedList *tl_next;
>       void *tl_tag; /* A unique identifier */
>       char data[0];
>    } TaggedList;
>
>Backends and overlays would union this with their own data and the push 
>items onto op->o_private as needed.
>
>Currently overlays can fake this by pushing a slap_callback instead, so 
>I guess it's not an urgent need. Comments?
>
>-- 
>  -- Howard Chu
>  Chief Architect, Symas Corp.  http://www.symas.com
>  Director, Highland Sun        http://highlandsun.com/hyc
>  OpenLDAP Core Team            http://www.openldap.org/project/
>

--