Jay Pipes wrote:
> Stewart Smith wrote:
>> On Sun, 2008-08-03 at 17:58 -0700, Brian Aker wrote:
>>> Hi!
>>>
>>> I worked out an example PAM authentication plugin this weekend. This
>>> is about what I learned:
>>>
>>> Server:
>>>
>>> There is quite a bit more that needs to be done on the server right now:
>>> 1) Final cleanup of old security context.
>>> 2) THD needs to be split out sooner then later.
>>> 3) We need to private'ize more of THD.
>>> 4) We use a VOID pointer to pass in a structure to plugins for init/
>>> finalize. I keep finding myself wondering if that should be a base
>>> class that we inherit from (aka I am starting to see certain patterns
>>> reoccurring in plugins).
>> I'm increasingly of the view that teh plugin init function should then
>> call functions in the server to register functionality.
>>
>> not the existing behaviour of casting then filling out the struct passed
>> in as void*.
>>
>> e.g.
>>
>> struct auth_basic foo = { blah, blah blah };
>>
>> plugin_foo_init()
>> {
>> register_auth_module(&foo);
>> register_func_module(&f);
>> }
>
> -1
>
> I would prefer not to get into the game of the plugin developer having
> to know a different function for each type of plugin they develop. Just
> do something like krow suggests with a base class inheritance:
>
> class plugin_base
> {
> protected:
> typedef enum
> {
> STORAGE_ENGINE
> , AUTHORIZATION
> , AUTHENTICATION
> , FUNCTION
> , PARSER
> , TOASTER
> } plugin_type;
>
> public:
> inline plugin_type get_type() { return plugin_type; }
> }
>
> class auth_basic :public plugin_base {
> auth_basic():
> plugin_type(AUTHORIZATION);
> }
>
> auth_basic= new my_auth_plugin(); /* Or could use a separate memory
> allocator */
> func_plugin= new my_func_plugin();
>
> Then, just have a single:
>
> plugin_auth_init()
> {
> register_plugin(auth_basic);
> register_plugin(func_plugin);
> };
>
> That way, plugin developers just call a single register_plugin()
> function and the kernel takes care of allocating/assigning the passed-in
> pointer to the appropriate HASH of plugins for that plugin_type...
What about plug-ins that both provide a storage engine, some functions
working for that storage engine, and throws in a toaster with the deal?
The problem with assigning a "type" to a plug-in is that the type is
singleton while plug-ins usually are packages that are loaded into the
server.
Using registration functions like Steward suggests would avoid some of
the problems (by allowing the plug-in to register/install any number
entities into the server), and the interface can be simplified so that
the developer does not have to memorize a lot of functions.
IMHO, the "type" of a plug-in, if there at all, should be restricted to
tell what functions are in the structure so that the host (server) can
call it correctly, but not be as narrow as to denote a single entity.
/Matz
>
> Anyway, I just scrapped up the code above. It's probably got errors,
> I'm just whiteboarding here...
>
> -jay
>
> _______________________________________________
> Mailing list: https://launchpad.net/~drizzle-discuss
> Post to : [email protected]
> Unsubscribe : https://launchpad.net/~drizzle-discuss
> More help : https://help.launchpad.net/ListHelp
--
Mats Kindahl
Lead Software Developer
Replication Team
MySQL AB, www.mysql.com
begin:vcard
fn:Mats Kindahl
n:Kindahl;Mats
org:Sun Microsystems
adr;quoted-printable:;;Tegv=C3=A4gen 3;Storvreta;SE;74334;Sweden
email;internet:[EMAIL PROTECTED]
title:Lead Replication Software Developer
x-mozilla-html:FALSE
version:2.1
end:vcard
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
