> We are going to be moving to mod_perl, but I am > worried about how to keep from getting into the same kind of trap with > mod_perl as with PHP.
You may want to read my article about building a large site with mod_perl: http://perl.apache.org/release/docs/tutorials/apps/scale_etoys/etoys.htm l. > So I am thinking whatever I do it should fit within an existing framework, > something like Mason. But I am confused about what real advatage Mason > provides, and how things like source code control would work if we are > running lots of servers. Your best bet to avoid spaghetti code with Mason is to use OO perl modules for all of the real functionality in the application and then use Mason's components as templates for displaying the results. Mason is good at handling the "plumbing" aspects of web development and provides an environment for doing HTML templates with in-line perl. See this article for more on appropriate use of components and modules: http://masonhq.com/user/autarch/Comps_vs_modules There are many frameworks for mod_perl, so if Mason doesn't look like exactly what you want you can check out some others here: http://perl.apache.org/#appservers > Do people use rsync to keep up to date? If you have a high-volume commercial site, you would be better off with a slightly more structured process. You can set up a script to make releases which will tag the CVS tree and build a release in some package format like RPM or .tar.gz. Then you can QA that release and later install the same release, all with development continuing in CVS for the next release. This allows you to easilly go back to a prior release if a disastrous bug is found in production. (Well, there are issues like config files and database changes which complicate things, but that's the basic idea.) - Perrin
