I want to 'moderize' everything, putting everything under a mod_perl/Apache engine to afford the speed bonuses, improve the database (currently in MySQL, but considering Postgres), and to make the site more 'personalized' for the end user by allowing them to select what styles or data they want to show, as well as any other means that I can think of. That's the goal, and I know that there are many ways to get there.
The problem is trying to determine the best way to get to that point given my requirements from where I am. I've got no qualms about rewriting my code to improve it, as there's not that much left to salvage. Fortunately, I'll be able to do this in parallel with the original site to avoid disruption in serving that one. Note that the hardware is a linux box on a 200mHz machine w/128Megs RAM; the site is active by endusers but not requiring massive amounts of bandwidth (maybe on order of 1000 unique hits/day), and the current site certainly doesn't strain the box to a great extent.
Here's some of the quandries that I'm thinking of:
- To monolith-ize or not? I could have all of the dynamic content come from a single script that uses a module like CGI::Application, with a callout table for given actions, and such. This way, I also gain the benefit of having cookie/login handling in one place for the entire site as well as easy ways to add new actions to the system. However, the types of actions that the end user can do on the site are rather varied, but no more so than, say, on PM. Since I'm planning on using mod_perl, that means every server instance will probably load all of the available method codes that I provide, which can be a bit memory heavy. Alternatively, using several smaller apps with a common module for cookie/login handling would not task the memory, but would require more careful coding. (I'd probably still need to develop a common code module if I do use a monolithic app)
- To XML-ize or not? I read this perl.com article on XML-based applications which described the use of XML as an intermediate layer between the DBI and the presentation, which allows for the application of XSLT style information before presentation. This can also mean one can develop XML streams ala the ones here at PM that the enduser can decide how to use to their likely. However, if the XML is only kept on the server side, these benefits can also be duplicated by judicious use of the various templating solutions like Template Toolkit 2, with the added bonus of reducing memory and CPU time before page generation. Since I can see that there are possible uses for a XML output from my site, I could either make the entire site use the intermediate XML layer, or I could simply provide XML when it's requested, possibly through a template solution again or just though the methods listed above, while the rest of the dynamic content is done directly through a template solution.
- (not quite as perl-ish) MySQL or Postgres? I don't have to worry too much about locking tables or transactions or similar features as this isn't a ecommerce site. The only key thing is that with a properly normalized database, I may need to do subselect statements that I believe Postgres can provide but MySQL can't (though can be simulated with successive SQL calls). I know MySQL tends to be faster but is showing it's age, while Postgres provides many of the advanced SQL features in the professional grade DB system at the cost of speed. While my current DB is in MySQL, I don't believe I'm using many MySQL-specific features, so I'm not too worried about switching it over to a Postgres.
-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com
||
"You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important