Singapore + PEAR:DB = !ctefs

Yep that's right. I've been looking around for a bit of info on Singapore's little-known option to use PEAR:DB as opposed to CSV files or automatic file info. If this works well, all I will need to do is make another table with just a "numid BIGINT UNSIGNED NOT NULL" (corresponds to the primary key of the image info table) and a "image_data MEDIUMBLOB BINARY" (very similar to the ctesqlfs's storage method). I guess i TIMESTAMP couldn't hurt, but it certianly isn't necessary. I could just put the BLOB in the image_info table, but this allows people to use a different table format better suited to large amounts of raw data.
The thumbnails might end up needing to be redone, but luckily, the thumbnails aspect of singapore is somewhat independent and simple.
A new user-accessible file would have to be made, called viewimage.php, which would take just the id # (something that doesn't exist at all in CSV mode singapore, just PEAR:DB), or if I'm not feeling lazy that day, maybe the option of file path too (after all, i suppose there is a function already written somewhere in Singapore that figures out ID # from path). Then the code that generates the XHTML img elements would be modded to use my system rather than traditional way.
viewimage.php might be able to just redirect to regular image in "galleries" directory if it isn't in the DB (another advantage of having a seperate table).
Another important thing viewimage.php should do (and this is something that is NOT done in unmodded singapore) is make sure the user has access to that image, and if not, output something like a mad cool "access denied" picture.

It would also be good to mod the admin system to use this, but that isn't imperative. I could just make a password protected independent script that you could upload an image to and specify a particular ID. Come to think of it, I'm not so sure the admin interface will work with PEAR:DB in the first place....
I would also probably write a script that just parses the galleries and then throws it all in the DB...after which it should be safe to delete the old "galleries" folder.

This approach has many advantages over the filesystem thing:

• simpler and less code
• probably faster (won't have to go through my multiple-inheritance system to figure everything out)
• better integration with singapore

There are some disadvantages, the biggest being that it would be impossible to have automatic indexes under this system.

At the end of all this, I plan to release a patch to singapore that gets the regular PEAR:DB stuff to work and then puts my stuff in.