in reply to architecture for module API

I did this for a build tool with pluggable commands driven by a build script. Can't comment on the security, since this wasn't an issue in my case. Still here are various comments
  1. I loaded the plug-ins as and when they were required, rather than loading all in one go. Means that I don't need to compile unnecessary scripts, though performance ain't an issue.
  2. A module containing common functions was very useful. This permitted the driver and plug-ins to share a lot of functionality particularly in error handling and reporting. This module also published various context information to avoid passing it all the time.
  3. In my case the single entry point was a sub with the same name as the 'plug-in'. However, if you have several entry points and they should be implemented by all the plug-ins you might want to go with an OO paradigm and derive your plug-ins from a base module that implements default entry points.