SlashCode compatibility with mod_perl 2 and PostgreSQL
Scoping the Problem

by Ian Kluft

This is where I'm posting notes, info and patches for my effort to port SlashCode to work with mod_perl 2 (Apache 2) and PostgreSQL. Initially this is to inform the Slash developers of what research I've done into the problem and what I'd like to do to make this happen. However, I know that in order for this idea to get anywhere in the long run, I'll need to coordinate with the Slash developers and gain their confidence. Without that, the large effort still ahead would not be worthwhile.

I'll offer to help maintain these features going forward. I know that makes a difference on whether it'll be accepted.

For background info, I've been maintaining a PostgreSQL-based internal SourceForge site (originally based on a CVS snapshot from just before it was withdrawn from the public) at work for 3 years. It isn't my primary job but it's an officially-sanctioned secondary task of mine.

Why am I doing this?

In late August 2004 I started working on porting Slash to a co-lo server of mine. (This is not related to my day job.) Slash currently supports neither Apache 2 nor PostgreSQL. So I had to take a hard look at it. I basically have three choices:
Use Slash on Apache 1 / MySQL
This option is a non-starter. I'm not going to downgrade my Apache server to 1.3. And having used MySQL, PostgreSQL and Oracle, I much prefer PostgreSQL.
Abandon Slash and use other software
I prefer Perl for this task. That pretty much limits the choice to Slash and Scoop. I like both. Slash seems far more actively maintained, and a better style fit for the sites I want to set up. It has years of learned lessons built into the system. (Perl's advantage here is in its vast CPAN library, including the Template Toolkit, and the ability to use cpan2rpm to smooth out module installation and maintenance on an RPM-based system.)
Offer to help the Slash developers with Apache2/PostgreSQL compatibility.
This started out as a daunting challenge. Though the size of the task is somewhat mitigated by the fact that both have been attempted before. The previous work needs to be updated but provides a big head start. But they weren't finished, or weren't presented in a form that the developers could readily integrate into Slash. (Note for anyone else thinking of something like this: if your patch only makes the software work on your system and breaks it for everyone else, no developer will accept it.) But I've done enough of the groundwork to believe it's possible... if the Slash developers will accept the help.
Given the choice, I would like to use Slash. It remains to be seen if I'll be given that choice. I set up the page to show status on what I've done so far, what I'd like to do and solicit comments on what could improve acceptability of this contribution to Slash.

What I've done so far

Overview status: So far everything here is untested. I've given up waiting for a response from the SlashCode developers and will proceed cautiously, hoping this meets with their approval and can go into the code base when it's ready.
Aug 25 - Sept 4, 2004
I've done enough to understand the scope of the changes needed for Apache2 and PostgreSQL compatibility. I want to run this by the Slash developers before proceeding, to get their suggestions and find out how receptive they'll be to this.

I started with Tyler McDonald's mod_perl 2 patch for Slash 2.2.6. I made an initial run through the code - this has not yet been tested but is provided as a note about what kinds of changes are anticipated.

I also scoped out the problem of what it'll take to make a PostgreSQL port. The Slash/DB/MySQL/ code is mostly not MySQL-specific and can be moved to a common base class, perhaps Slash::DB::Common for example. Then PostgreSQL compatibility can be added by writing a much smaller number of functions for that interface. Notes will also be needed for other developers to explain how to make sure new code remains portable among all the supported database interfaces.

Sept 6-7, 2004
Here are initial runs with the mysql2pgsql program.

Sept 8, 2004
A parallel effort on mod_perl 2 compatibility has been brought to my attention over at the FreeBSD project. Although it looks like he just used Tyler McDonald's patch from February, which may or may not be adequate for the version of Slash currently in the FreeBSD Ports. I'll invite him to use my patch as soon as I've tested it, and will also include anything he finds.

I still haven't heard anything from the Slashcode developers, neither positive nor negative and no advice on what they prefer. I suspect they've seen a lot of false starts on efforts like this, and won't take it seriously until it's working. I'll proceed cautiously and hope they approve of my work.

I've started updating a page of notes on database portability in SlashCode as I work on the MySQL/PostgreSQL portability patch.

BTW, I'm not planning to do Oracle compatibility, since I have no interest in maintaining that. Though this should lay most of the groundwork for anyone who does want to do and maintain that.
Sept 9-16, 2004
OK, I give up for now on PostgreSQL. I'll continue with mod_perl 2 and leave the PostgreSQL patch for a later upgrade. The Slashcode developers just did a huge MySQL-specific CVS commit. Though I've been following them every day for the past week, the latest one was too much. I don't have forever to get my site up and running.

I did a lot of work on PostgreSQL compatibility. Here's the untested diffs of where I was at. It annoys me that the Slashcode developers never gave a positive or negative response to my offer to help. The INSTALL file says about the possibility of other databases, "Patches and feedback are, of course, always welcome." Yet they sent other messages to the slashcode-developers list after I got no response, and kept modifying the code base with more MySQL stuff. I can only do this PostgreSQL work with at least some cooperation, but so far I've gotten none. I'll keep trying.

I can tell this will be a tough nut to crack. I'll try to use the mod_perl 2 patch to get their attention and gain their confidence.

I'll relent for now and go with MySQL on my site. I really didn't want to run two different databases.

(Grumble. It's like they're off in their own little world... OK, I just needed to vent but I got that out of my system. They don't know who I am and it's not my project so I have to be nice to have a chance to get this in there.)

Useful links