I'm also writing a large web app and, even though it's basically a monolithic CGI (don't worry- FastCGI!), I also wanted to integrate some method of expansion. I am accomplishing this with a sort of menu page where various functionalities can be chosen or decactivated and a further page where each "program module" (Not necessarily perl module) has some preferences/ configuration page (or new window?). Each "program module" is supposed to provide a different filter or different editing functionality for the data set provided. I have not yet documented how one builds such a module since it involves modifying some hashes in the main CGI script. But the basic way to link in a module so that it is recognized is through my /etc/myprog.conf file which I parse at script startup (easy enough in perl!) with keywords like 'UseModule' and 'ModulePath'. After checking that the file exists, I import it (it's an actual perl module) and call a standard function which links it's hashes with the main CGI's hashes which in turn will be displayed in a select menu on the final HTML page. While this in no way simplifies the manner in which a user can come up with his module (until i cough up some documentation), this simplifies the manner in which I am able to manage each module individually and expand at will.

This method of expansion gives me quite a few more advantages over your "create-a-new-markup-lanuage" method:

• I don't need to redesign a language, deciding on the most important parts and perhaps extending the language in a future version.
• I automatically use a fully-featured language which allows any module to do anything within it's permission set.
• I don't have to come up with a parser.
• No one needs to learn a new language (unless he doesn't know Perl) and only a quick EXPORT and a standard function is needed in the module. The rest is left up to the programmer.
• Modules can be added or disabled in various users' configurations very easily without keeping track of a whole bunch of files.
• Modules can affect virtually any part of the program as opposed to a limited language.
• Virtually no chance of big bugs in the parser since you're using Perl!
• speed

Also, as your program progresses in version, the perl modules can be morphed to C, Pie-thon, or any other language users wish to see (can you say Rexx?). If you are able to come up with a strong and basic core to your web app, the functionality can be built out of shared modules (shared among the instances of the CGI) and a version upgrade would simply entail a module upgrade. Errors and bugs can be easily eradicated by isolating and repairing single modules! I thought it through for a while and I came up with a different solution but decided the aforementioned idea would be more efficient: I considered writing a daemon that would manage a bunch of mini-CGIs that would in turn be responsible for the dbengine calls. the daemon would handle user info and the config file. But then I just defaulted to fastCGI. You might also look into some current so-called "web objects servers". Have fun with GPL!

AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.