architecture for module API

dash2 has asked for the wisdom of the Perl Monks concerning the following question:

Here's a puzzler. I am trying to write a script which can handle plugins, so that installing a plugin is as easy as downloading it and putting it in a specific directory - the script will automatically detect and use it at several points.

One requirement is security: I think this is satisified by making sure the directory can only be written to by the owner of the script, so if he/she puts stupid stuff in there, that's his or her fault. Another requirement, pulling the other way, is future-proofing: it should be able to handle upgrades and plugins I haven't thought of yet. A final requirement is ease of use: no renaming stuff, no command line fiddling, just download and go.

My initial thought is as follows:

Create a module handling script. This "require"s all the files in the plugin directory. It then executes the relevant subroutines in those files (see below).
The original script calls the module handler at several defined points. The module handler knows where it is being called from.

Each plugin script will consist of a hash of switches, plus some subroutines. E.g.:

$can_be_called_from = { 
   foo => 1,
   bar => 0,
   baz => 1
};

sub foo { ... }
sub baz { ... }

1;
[download]

When called, the module handler checks each script for the relevant switch:

foreach ($plugin_script) {
   require $_;
   if ($plugin::can_be_called_from->{$where_I_was_called_from}) {
      #call the relevant subroutine
   }
}
[download]

I have some worries about this.

(1) Is it really secure?

(2) I don't seem to be using the Perl module system very effectively, except to distinguish between different plugins' $can_be_called_from hashes.

Can anyone suggest an improvement, or some useful thoughts about this architecture problem? Either Perl-specific comments, or general ideas, are welcome.

Cheers,
Dave

Comment on architecture for module API Select or Download Code

Replies are listed 'Best First'.
Re: architecture for module API by Tyke (Pilgrim) on Feb 21, 2001 at 17:16 UTC
I did this for a build tool with pluggable commands driven by a build script. Can't comment on the security, since this wasn't an issue in my case. Still here are various comments I loaded the plug-ins as and when they were required, rather than loading all in one go. Means that I don't need to compile unnecessary scripts, though performance ain't an issue. A module containing common functions was very useful. This permitted the driver and plug-ins to share a lot of functionality particularly in error handling and reporting. This module also published various context information to avoid passing it all the time. In my case the single entry point was a sub with the same name as the 'plug-in'. However, if you have several entry points and they should be implemented by all the plug-ins you might want to go with an OO paradigm and derive your plug-ins from a base module that implements default entry points.	[reply]
Re: architecture for module API by AgentM (Curate) on Feb 22, 2001 at 02:28 UTC
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.	[reply]
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]

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.