Jay Pipes wrote:
> Mats Kindahl wrote:
>> 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?
>
> That's what the code above does...it registers an auth plugin and a
> function plugin...
>
>> 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.
>
> How is a type a singleton? The type is merely an attribute of the
> plugin, no?
>
>> 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.
>
> Isn't that what the plugin_auth_init() function in the code above does?
> What am I missing?
Sorry, I misread the code to be the same as the current MySQL plug-in
system. No, the code above is good: no objections (except that passing
classes back and forth between the server and the plug-in will not work
across compiler implementations because of differences in class layout).
>> 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.
>
> OK, good point -- so here is another idea: use interfaces to allow the
> plugin to "describe" to the host what it does. This would be C++, but
> in C, the concept would be something like the struct of function
> pointers that others have suggested -- with the plugin setting to NULL
> any "ability" it did not have. Correct?
Not sure I follow what it is you are thinking about. Could you give an
example?
/Matz
>
> -jay
>
>> /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
