SlashCode compatibility with mod_perl 2 and PostgreSQL
by Ian Kluft
Scoping the Problem
This is where I'm posting notes, info and patches for my effort to
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
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:
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.
- 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.
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.
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
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.
- 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/MySQL.pm 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
as I work on the MySQL/PostgreSQL portability patch.
I did a lot of work on PostgreSQL compatibility.
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.)