With Slash up and running, you will probably want to make things look a little more homey. The key to advanced customization is understanding how Slash fits together. This appendix walks through the basic design and explains how things run. It is intended to help you understand how the individual components work, so you will be prepared to make your own changes.
Slash is tied heavily to the Apache request cycle. Further, it is broken into multiple components, each supported by its own libraries. This modularization makes it possible to modify one kind of behavior without having to know how the underlying support structure works. The only pieces of Slash that do not fit this model are the housekeeping daemons, covered in Section 11.2 in Chapter 11.
Apache begins life by reading its configuration file, performing any
initializations its modules require (see Figure A-1). Slash
uses this stage to initialize several of its own components. For instance, the
guest user is created during this stage. Slash also creates all of the menus
for a site and stores all of the constant site configuration data (e.g., site name,
document root, administrator name, etc.) in a hash. Consequently, any
changes to this information require a complete restart of the web server to
take effect. Global requirements are stored in
/usr/local/slash/httpd/slash.conf, and each site has its own configuration file in the root of its site directory. This ...