musings of wrath

I just got finished building, testing and launching a simple application for a client of ours using the PEAR package DB::DataObject. I also used the Form_Builder class that’s based on DB::DataObject, but it’s not very well documented, and doesn’t really have a complete API.

I have to say, that has been the fastest development time I’ve ever had for a database application from scratch. 9.5 hours, including the administrative functions, bug testing, and bug fixing, is all it took. It isn’t pretty, and could use some color, but that wasn’t my goal - it was to build a functioning web-based file manager from scratch, and I did it.

Why, you might ask, does a web-based filemanager need a database for anything other than authentication? Simple - I needed to be able to track all of the files, and have a method of assuring that the data was preserved properly - regardless of platform.

Here’s how it works:

Each time a file is uploaded, the application generates a UUID, and saves the file with a filename OF the UUID. It then stores into the database the UUID (as a primary key), the original file name, the current path (for future expansion), the mimetype, the user ID of the uploader, and other logging information. When someone retrieves a file, it takes the UUID from the URI and pulls the information from the database, opens the file for reading, and puts out a couple of Content-based HTTP headers before streaming out the data. The end user gets a save dialog (if their browser accepts the “disposition” data), with the correct, original, filename. The user never knows where the file is stored, and could not possibly guess the filename based on the UUID. This allows for privately exchanging files through this system, the only time the filename appears is when the Content HTTP headers come across the wire.