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?
> 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?
-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
>
>
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
