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.

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.

• registration of all plugins upon program startup - the above can handle this
• initialization of plugins - put any initialization code in constructor
• activate plugins - need to have something like an activate() method in the plugin class
• cleanup of plugins - More important for C than Perl, but plugins may need to write preference files, etc.

1. Define what can vary. This is harder than it looks and is the most important feature of all.
2. Define what interface the varying bits are required the conform to. They may provide more than this, but they have to provide at least this much.
3. Write a plugin loading scheme. Module::Pluggable is good. Mason and CGI::Application both have their own. Mason's is more defined as opposed to C::A's which is more Wild-West'ish.
4. Sit back and let the users do what they need to do.

Note: Plugin systems can get very complicated. Take a look at what DBI does, one day. That's complicated!

Another plugin system of note is the XML::SAX stuff.

Also, here's an article on a real world application using it (this one is written in German, though).

Never implemented plugin support before, but just a thought: would not plugin support be analagous to designing a system for creating modules for a programming language? This comes to mind because some languages do this better than others, and that might also give some best-practices guidance (e.g., compare modules in perl with modules in PHP).

Another module that might be suitable for you is Module::Find. I wrote it for an application where I needed plug-ins myself. It's nowhere near as full-featured as Module::Pluggable, though.

The only "core" was the definition of the data plugins knew about, the MVC-esque "model" of the program.

The program was then (in theory) reincarnated many times into byte sized scripts, that, for example, load the plugin-loader-plugin, which assumes plugins are Module::Pluggable like in their format, and then loads them up.

The system I wrote to back this up was centered around totum-pole objects. The instances of the plugin objects were joined into one object, which pretended to be all those objects at the same time. Each plugin had it's own private space, it's own instance, and there was a clear api letting you talk to other plugins.

The general design was that a plugin was either a sort of care taker for a certain group of plugins, which is responsible for arranging for proper dispatch of a method, or something having to do with how simple plugins work together, or it is a plugin that provided functionality, and is arranged by some other plugin.

To pipeline an operation, for example, you need about 5 lines of code in a caretaker plugin, simple filter like plugins which get and return much of the same data. To do type or capability based dispatch, for example, to make the method "ring" work on both bells and piano forks, you define some sort of protocol, to find out which plugin likes what:

package Plugin;
...
sub process {
   my $self = shift;
   my $foo = shift;

   $foo->FooMethod();

   ...
}

sub processes {
    return qw/Foo/; # this module's process method likes objects which
+ isa Foo.
}
[download]

sub process {
    my $self = shift;
    my $obj = shift;
    my @args = @_;

    DISPATCH: foreach my $plugin ($self->host->stack("process") { # th
+e stack of plugins that ->process
        foreach my $class ($plugin->processes){
            next unless $obj->isa($class);
            return $self->host->specific($plugin)->process($obj, $args
+);
        }
    }
}
[download]

package Plugin;

sub process : expects(FooClass) {
    my $self = shift;
    my $foo = shift;
}
[download]

Anyway, without further ado, I give you Object::Meta::Plugin.