Administrators and Authors can run a successful Slash site quite well with the information presented in previous chapters. A bit of initial customization and preventative maintenance will keep the site running for ages. There’s a class of people, though, who like to take things apart to see what makes them tick. The relative ease of Perl programming and certain design decisions by the Slashteam make this especially appropriate.
This chapter explores Slash architecture from a nuts-and-bolts perspective. Readers with a little Perl, SQL, and Unix under their belts will get a feel for the architecture of the program as it works. It’s a little noisy behind the curtain, and sometimes the floor is greasy. Step carefully.
To perform advanced administration, you must understand the Slash architecture, API, and even several common database tables. The good news is that you don’t have to be an expert to do interesting things. That’s the Perl way. This chapter should be read in conjunction with Appendix A, Appendix B, and Appendix D. (They may be short on suspense, but they’re tall on detail.)
All of a site’s tasks live in the
subdirectory. They must be valid Perl files (or symbolic links to valid Perl
files). Their names must end in “.pl” and should contain only
alphanumeric characters or the hyphen.
Internally, tasks must provide two pieces of information: a time specification used to schedule the task and a Perl subroutine to be ...