The details below are very much out of date, I haven't scrapped the archive paradigm, but with all my development time invested in 1vCMS I have had no time to work on eTs. I think I may re-work eTs as an extension of the 1vCMS codebase at some point.

At the begining of 2001 and I decided to draw three panel quick-gag comic strips for the EternalKnights IRC network, called EK: Tha Strip.
To aid archiving of the scripts I downloaded Keenspots.com's free PERL archiver. I found it good, but really limited and basic. For one I couldn't load the latest strip on the front page or give a list of comics.
So I wrote my ow scripts in PHP to extend the archive. Took me a while but they worked.
Afterwards I decided, why not just write my own archive?
So I spent a good solid 48 hours creating one. eTimes Strip v1.0 was born.
eTimes because the strip was originally meant to be displayed in an eZine called EternalTimes, which used my own content management system, so I designed eTimes Strip to be an add-on for it.
During the summer I'd built up a good archive of scripts and the present script was choking on dealing with the amount, b/c of the shitty listing code I used. So I rewrote it from the ground up, it was 70% faster and worked damn nice with some extra features.
But it wasn't perfect, so I've been working on a better version, v3.0 since I'm doing another complete rewrite. I've stopped work on EK: Tha Strip (or just Tha Strip as it now is), but I create The Goldfish Bowl with my good friends Darren and Joff. eTimes Strip v3.0 is the system which powers the archive on gfbowl.com.
The v3.0 codebase isn't fully complete yet, but its getting there. Along with v3.0, comes v1.0 of stripDB. stripDB is a flat text file based database; I went through three phases, originally using symbol seliminated text files, then using XML which could easilly be parsed, but now the latest version generates PHP code. When a DB is called the script merely includes the stripDB functions and when it calls the functions, stripDB decides which files to use and includes the PHP files for them, and the PHP4/Zend engine parses those files natively. As everything is done inside the engine all the data for the archive is parsed blazingly fast (faster than an SQL database), but because only the information needed (everything is optimized for comic strip archiving) is stored and called, there is barely any bloat.
The reason I started work on stripDB is because I couldn't see the point in using other more complicated DB systems (like *sql), and when I saw the work a friend of mine had been doing on the DB system for Ikonboard (including a sneak peak at the PERL code for it), I decided to make a DB system that was designed for the archive and so would worker more efficiently.

Soon I'll put more info here on the advanced features of the system, and hopefully info on a release. That's all!