Re: architecture for module API

I'd have to take argument to your model. I would strongly recommend an Apache-style model: the configuration file. This gives the user the benefit of not only being able to centrally view all of the plugins but it allows for the plugins to be wherever the user wants them to be (directory cleanliness). In your current model, to disable a plugin, it is removed from the directory. I'd consider that an unecessary hassle. In the conf file, all you would need to do is comment and uncomment some line.

How about plugin options? These can be easily specified in the configuration file. Your model doesn't provide for this unless you ask the user to hack the plugins directly.

I find it much more comforting if I know exactly which modules and libraries are loaded by a program rather than specifying some arbitrary directory. A central configuration file gives me the control of the program that I need. And remember, the configuration file can be used for more than juts plugin specs! Good luck!

AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.

Comment on Re: architecture for module API

Replies are listed 'Best First'.
Re: Re: architecture for module API by dash2 (Hermit) on Feb 22, 2001 at 15:04 UTC
AgentM, Yeah, your points are well taken. I'm actually planning web-based admin for this thing (see some of my other posts), so part of the plugin's functionality will be "administer the plugin". As for removing plugins easily... good point. I already have a nifty, easy-to-extend config architecture using FreezeThaw.pm and a bunch of $SETTINGS hashes, so I could include a $DISABLED_PLUGINS hash: `$DISABLED_PLUGINS = { nogood.pm => 1, notneeded.pm => 1, ... }` [download] Thanks for the point. dave	[reply] [d/l]

Replies are listed 'Best First'.

Re: Re: architecture for module API
by dash2 (Hermit) on Feb 22, 2001 at 15:04 UTC

Yeah, your points are well taken. I'm actually planning web-based admin for this thing (see some of my other posts), so part of the plugin's functionality will be "administer the plugin". As for removing plugins easily... good point. I already have a nifty, easy-to-extend config architecture using FreezeThaw.pm and a bunch of $SETTINGS hashes, so I could include a $DISABLED_PLUGINS hash:

$DISABLED_PLUGINS = {
   nogood.pm => 1,
   notneeded.pm => 1,
   ...
}
[download]

Thanks for the point.
dave

[reply]
[d/l]