diary livejournal fossils

First of all, it needs a good name. I don’t want to just call it ‘RF!P Manager’ or anything, and I’ve pretty much exhausted adding ‘Fox’ to the front of my project names.. Oh well. If anyone has any suggestions, feel free to let me know.

The actual content managing program would be pretty short; all it would have to do is read in a file containing a list of extensions and the plugin associated with them, then read in the extension file and eval it with either the name of the file or a filehandle passed to it (perhaps open to a scalar filehandle, so you have the filename, too, and don’t have to access $ENV{‘PATH_INFO’} all the time) along with the CGI handler (add $ENV{‘PATH_INFO’} args to CGI params).

An example url would be ranna.bolognia.net/man/addtable.atm, which is just an html file that requires the user to be logged in to access (Admin::HTML). The atm file has a form who’s action url is /man/addtable.adm, where adm is aliased to the function Admin::Admin which requires a password. The addtable would create an SQL file with the suffix .asql and link to it. The extension .asql is aliased to Admin::SQL, which would decide whether to $dbh->do() or $sth = $dbh->prepare(); … it, and require a password in the process.

/man alone would have a default action to parse ($action = $ENV{‘PATH_INFO’} || “/index.html”;). /man/.ext would dump information about the extension ‘ext’ (a third field in the config file? extension subroutine info-file)

An idea for a configuration file: # Admin types: .ah?tml? Admin::HTML ahtml.nfo .adm Admin::Admin admin.nfo .asql Admin::SQL asql.nfo