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.
-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com
||
"You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important