|There's more than one way to do things|
Plug-in architecturesby Masem (Monsignor)
|on Mar 14, 2002 at 01:33 UTC||Need Help??|
People have brought up the concept of plug-ins in perl, such as at Plug-in mechanism implemented in Perl (with the first response giving other searches). The concept here is that code is self-contained in a separate .pm file but located outside of @INC. However, in the FBP system I've been looking at, I'm considering a plug-in system that operates in a slightly different fashion, and based on what I've done with Java in the past.
First, plugins make a bit more sense here than trying to have everything drop into @INC. Since not every plugin could be used by the user at any time, it's probably smarter to keep the call table clean and only load modules when needed. In addition, it would seem to be much more easier for the user to manage without adminstrator help (though normal perl mods should also work the same way).
However, I envision that some of the plugins that could be written would require additional files, either in the way of extra perl code, glue libraries, config files, text files, or whatnot. Again, these could all be installed into @INC without problem (and be referred to), but now you start to get a messy plug-in directory.
If you look at (at least early versions of) Netscape, Photoshop, etc, plugins were single files; on the Mac side, this was 'easily' accomplished using the resource fork, and I believe similar tricks were used for the PC side. When I tried this in Java, I used .jar files to group class files and other files into a single package. The natural extention in perl is tar.gz files. Inside the tar.gz. file would be some manifest file (say, XML based) that would tell the program where the key class is and any other important files might be located.
The idea would be that at startup of the program, the various directories that have been indicated as plugin dirs (including a program default, system local, and user local set) would be scanned; each file in those dirs would be tested as a tar.gz file, then opened to look for a manifest file (as by a fixed name). At this point, the plugin name and location would be set up into a global hash. At some point, when the plugin is needed, then the necessary code is dynamically loaded using the location info and temporary strings as obtained from the tar.gz file. Plugin authors would have the ability to grab any other data files from their plugin archive via provided code.
Does this approach seem reasonable, has it been done before, or does it seem over the edge for what it needs to do and in this case just rely on @INC to provide what's need? The only problem of this latter solution is that how one determines which files are plugins for the system in question or not.