Re: Plugin Programming

I wish I could point you to some resources on the topic, but I can give you my experience with Perl and plugin development.

Generally, each plugin should have a single point of interaction with your program. Normally, this is a package that implements an interface specified by the application. Then the plugin can have its own set of supporting libraries.

So, you might have an interface that all plugins meet. The interface can be as simple as a list of methods that the plugin's implimentation class needs to support. However, you could provide a partial implimentation that can be subclassed by the plugin developer.

Here is an example of how you might load plugins in your application. In this example, each plugin is a PM file located in a directory called plugins.

sub LoadPlugins {
   my %plugins = ();
   for (<"plugins/*.pm">) {
      my ($pluginName) = /plugins/(\w+)\.pm/;
      require $_;
      # Create a new instance
      $plugins{$pluginName} = $_->new;
   }
   return %plugins;
}
[download]

Now, this is a very simple example, but should get you started.

Ted Young

($$<<$$=>$$<=>$$<=$$>>$$) always returns 1. :-)

Comment on Re: Plugin Programming Select or Download Code

Replies are listed 'Best First'.
Re^2: Plugin Programming by gaal (Parson) on Feb 14, 2005 at 16:25 UTC
Great advice! I realize the code above is just a demo and not a full implementation, but just a note on coding and error handling as appropriate here. I'd rewrite some of the above like this: `eval { require $_; my $plugin = $_->new or die "failed to instantiate\n"; $plugins{$pluginName} = $plugin; } or logger("failed to load plugin: $@");` [download] Plugins can and will fail, so treat them with some skepticism :) -- this is actually a benefit of decoupling that you can afford to keep the main application running even if a plugin failed. In terms of development, if you expose a mechanism to rescan the plugin repository, you can reattempt to load a failing plugin without restarting your application. (Theoretically you could also implement plugin unload routines, but that's harder.) Plugins are a great opportunity to use either interfaces or traits. Getting compile-time (or at least, plugin load-time) verification that it conforms to the plugin interface is nice.	[reply] [d/l]

Replies are listed 'Best First'.

Re^2: Plugin Programming
by gaal (Parson) on Feb 14, 2005 at 16:25 UTC

I realize the code above is just a demo and not a full implementation, but just a note on coding and error handling as appropriate here. I'd rewrite some of the above like this:

eval {
    require $_;
    my $plugin = $_->new or die "failed to instantiate\n";
    $plugins{$pluginName} = $plugin;
} or logger("failed to load plugin: $@");
[download]

Plugins can and will fail, so treat them with some skepticism :) -- this is actually a benefit of decoupling that you can afford to keep the main application running even if a plugin failed. In terms of development, if you expose a mechanism to rescan the plugin repository, you can reattempt to load a failing plugin without restarting your application. (Theoretically you could also implement plugin unload routines, but that's harder.)

Plugins are a great opportunity to use either interfaces or traits. Getting compile-time (or at least, plugin load-time) verification that it conforms to the plugin interface is nice.

[reply]
[d/l]