In such cases (extending a framework simply by adding classes and having all changes local to these classes), I use a central registry (either the Windows registry, a singleton object in my program or an external text file). That registry consists of two fields per entry, name and service. The name field is unique to allow identification (this could be the filename of your plug-in), the service field contains the name of the service this module provides (in other contexts, this is called an interface).

In order to make installation as painless as possible (simply copy a file), you could blindly require() all .pm files in the plug-in directory, and evaluate the &getServiceName() function that every plug-in must export. This also makes deinstallation painless, but it makes each program startup slow, as every plug-in must be loaded, even if it's not used at all.

This scheme dosen't relieve you of specifying what happens when two plug-ins supply the same service, but the program will only either one of these two plug-ins - here some UI/configuration would be in order.

For this, I would use Exporter. Every plugin loaded (use'd) simply overwrites the main namespace with the new function. It's than up to the plugin to determine if it's right to overwrite or not. You can search the namespace with %::. Additionally, with @EXPORT_OK, the API can determine which names to import.

If you set up the API like this, the order in which the modules are loaded is important. Therefore, add the name of the plugin when it's downloaded to a config file. Upon restart, load the plugins in the specified order, to achieve the same state.

For example, if your API contains the function 'my_sub', the package 'plugin.pm' would EXPORT 'my_sub', thereby overwriting the API's sub.

You can extend this even to OO-perl, methinks.

Hope this helps,

Jeroen
"We are not alone"(FZ)

beautiful. that's so simple, elegant and obvious I am kicking myself for not thinking of it. yippee. /me kisses jeroenes.
dave

As Corion already suggested, I'd use require to pull in the modules you need.

I would ensure plugins are installed in a special directory, outside Perl's normal @INC, which only contains plugins.

I'd write an AUTOLOAD subroutine in the main code using File::Find to determine the names of all plugin modules (and cache this information to speed up subsequent calls to AUTOLOAD), then require in any module whose name matches the plugin you are looking for.

I'm not sure how you'd deal with multiple plugins that offer similar functionality, such as Module::Offering::this and Another::Provider_of::this, but then I'm not totally clear on exactly what you want to achieve.

I hope this is useful. Of course, TIMTOWTDI!

That sounds rather clever to me. So, my AUTOLOAD routine would check for plugins with the required subroutine, but failing that would just use the default. In effect, all my subroutines would be routed via AUTOLOAD first...

Yeah, that is a really nice solution - my only worry wd be, will all the AUTOLOAD calls consume a lot of time and CPU? I guess there's no easy way round that anyway. If I want easy plugins, I have to get runtime subroutine lookups.

thanks a lot
dave

If your subroutines don't do much work, or you're calling them recursively, then the overhead of an AUTOLOAD technique might be prohibitive. Otherwise, I wouldn't worry about it.

I recall Damian Conway's Object Oriented Perl describing a technique to declare subroutines when AUTOLOAD is called, so after the first call there is no AUTOLOAD overhead. If you're concerned enough, you might want to investigate that.

Update: The syntax for this is:

*{$name_of_subroutine_to_create} = \&Name::of::existing::subroutine
[download]

If you want the reverse of inheritance, then reverse the inheritance. Have each plug-in do:

unshift @MainPackageIReplace::ISA, __PACKAGE__;
[download]

Nice idea, but that wouldn't actually override functions in the main package, would it? E.g.

package MainOne;
sub foo { ...}

package NewPlugin;
unshift @MainOne::ISA, __PACKAGE__;

sub foo { warn "new plugin!" ... }
[download]

Now calls to MainOne::Foo would still go to MainOne itself, right? You could provide new functions with this idea, but not override existing ones.

dave hj~

My suggestion would be similar to the 'registry' idea, but rather than listing out the various plug-ins in a central file, which will have to be maintained in some way (RegClean is your friend), you could grab the first x bytes of each file and search for the @ISA and package declarations.

(You might also want to check the eol characters (\012 vs \015 vs \012\015), depending upon how much you trust your 'potentially naïve end users,' to borrow a Micros0ftian phrase.)

Depending upon local system configuration, &c., a 'chunk' size of 512 bytes or 4KB might be best. (iirc, 512 byte blocks are +/- standard on most Unices, MacOS, and ?Win/DOS?. 4KB is the size of Linux's read-ahead, and quite likely other OSen, so if you read 1 byte from a file, it's likely that 4KB are cached by the OS, you'd just as well use them.)

Regardless, parsing the package and @ISA elements in the first "chunk" of the file gives you a simple way to identify the parent class to be replaced, and the name of the class to import (assuming that the filename itself is likely to be truncated, modified, or generally abused.)

Rather than manually parsing the files consider this snippet. Since perl already maintains a registry of installed modules (ExtUtils::Installed), why write your own?