Running Weblogs with Slash

The Slash Architecture

In Version 2.0, Slash underwent a complete architectural overhaul. The new Slash provides features such as themes, database abstraction support, an API for the database, use of the Perl Template Toolkit, an improved and streamlined installation process, hooks to support addition of third-party modules, and better support for hosting multiple Slash sites.

Slash has always been Free Software, available under the GNU General Public License. With the open-sourcing of the MySQL database, all of Slash’s underlying infrastructure is now open source as well. Slash is built on the Apache web server, the mod_perl Apache module, and a relational database that speaks Structured Query Language (SQL). (MySQL is supported out of the box. Some work has been done to port things to the excellent PostgreSQL database, though it lags behind. Oracle has some preliminary support.)

At the bottom of the traditional software architecture “layer-cake” diagram (see Figure 1-12) squats the operating system. Slash was born on Linux and has been run successfully on FreeBSD, OpenBSD, and several commercial flavors of Unix, including Solaris and HP-UX. As of this writing, Mark Breitenbach ([e-mail]) has ported Slash 1.x to NT; track the progress of the port at http://geo.trippy.org/nt-slashcode/.

Figure 1-12. Diagram of Slash software infrastructure and architecture

The web server and database server sit on top of the operating system. Slash requires Apache, the world’s most widely used web server, compiled with the mod_perl module, which adds a Perl virtual machine running inside the Apache process. This enables Perl applications such as Slash to run as persistent “applets” instead of forked-off children using the Common Gateway Interface (CGI). When Apache starts, it compiles and loads these applets, initializing them (including retrieving configuration data). They remain in memory to handle client requests. This spends more memory on Apache child processes but improves performance by avoiding the delays of loading, compiling, and initializing a separate CGI process for each client request.

Any of several SQL-compliant database servers may be used with Slash. Slash initially worked only with MySQL, but the 2.0 redesign added a layer of abstraction to enable easy porting to other SQL databases. The database stores all of the information that makes up the site: Stories and comments, user data and preferences, layout templates, comment filters, and poll results.

Slash itself is made up of four kinds of Perl programs:

Applets

The Perl programs that run inside the Apache web server process. Like CGI programs, each has a URL and is executed when the web server receives an HTTP GET or POST request for that URL from a web browser. The applet then generates an HTML page which is sent back to the requesting client. Examples of Slash applets are index.pl, which generates each user’s custom view of the site homepage, and article.pl, which does the same for individual Story pages.

Tasks

Programs that run independently from the web server. The slashd daemon schedules and runs them. Tasks are small programs that perform various system tasks, often updating site content or keeping things in order. For example, the portald task fetches RDF-format content from elsewhere on the web to update Slashboxes, and generates the site’s own RDF file for others to grab. Section 8.2 in Chapter 8 explains these programs at length.

Utilities

Standalone programs that run on an as-needed basis when invoked by site administrators or daemons. We have already discussed the dailyStuff program, which sends out nightly headline mailings. Other utilities are provided for analyzing suspiciously high levels of activity and other common tasks.

Modules

Perl libraries defining objects and functions used by the other programs. The most important of these are, in brief:

Slash.pm

The original workhorse, this is the standard entry point for common, high-level functions called by applets and plugins. These range from operations such as “give me the HTML for pop-up menu of the site’s Sections” to “give me an HREF link tag to Story ID foo.” Most of these functions live in other packages; Slash.pm exports them for convenience.

Utility.pm

Defines lower-level functions called by Slash.pm, such as “tell me who the current authenticated user is, if any.” Functions in Utility.pm are used both within Apache (i.e., by applets) and from other processes (such as the daemons and utilities).

DB.pm

Provides high-level database functions such as “fetch block motd from the database.” DB.pm doesn’t actually implement any of these functions itself. Instead, there is a separate, specific library for each of the supported databases (MySQL.pm, PostgreSQL.pm, etc.); when anybody asks DB.pm for anything, it delegates the job by cleverly choosing the right database-specific module from which to inherit that subroutine.

Display.pm

This module (and its friends) add support for the Perl Template Tool- kit by Andy Wardley (http://search.cpan.org/search?dist=Template-Toolkit), “a collection of modules which implement a fast, flexible, powerful and extensible template processing system.” This system defines compo- nents of web pages containing embedded variable references which are replaced with the corresponding values when the page is requested and viewed. Appendix C discusses working with the Template Toolkit in Slash.

Apache.pm

Apache’s module interface lets programmers change just about any aspect of the web server’s behavior. The Slash modules Slash::Apache, Slash::Apache::User, and Slash::Apache::Log use this interface to get under Apache’s hood and handle some of Slash’s needs earlier in the request-handling process than could be done otherwise. User.pm gets Apache to handle user authentication against the Slash user database, Log.pm handles any logging that should go to the Slash database instead of the standard Apache logs, and Apache.pm makes it easier to configure Apache to run multiple Slash sites on the same machine.

Appendix A catalogues the main modules and describes their main functions. Two other types of components are necessary for site operation: themes and plugins. Themes are bundles of templates and applets that control the presentation of data. Plugins are bundles of applets and data that add new behavior to a site. The default Slash behavior (Slashcode-clone) is itself implemented with the Slashcode theme and the Admin plugin.