Per user request, I spent the last couple of days feverishly coding up a file system based organization for Plogger in order to augment and extend the current system based on a MySQL database. However, I have come to a bit of a conceptual dilemma when it comes to the implementation of this functionality. In this new version, when you create an album or collection, the corresponding subdirectories are created within the /images/ directory. Fine. All files are uploaded to their corresponding directories so you have a nice file structure like /images/collection/album/image.jpg. When you make a change to an album’s name, the directory name changes, the database path fields for each picture within that album are updated, and so on. The trick is not to make any physical changes to your images file system and trust that the administrative web interface will keep your files neat and organized. Simple enough.
Now the question of handling new pictures (mass import) via FTP comes into play. Here are the possible scenarios.
Scenario #1: The user uploads everything into the /uploads/ directory with their FTP client, as they do currently with Beta 1. The only difference is now the user can utilize the file-based organization they have setup on their hard drives; they upload folders they wish to become albums inside folders they wish to become collections. The import function parses all this information out of the directory names and spits everything into the database, moving everything from the /uploads/ directory to the /images/ directory in the process. Albums and collections that do not exist in the database are created on the fly. If a user tries uploading folders with only pictures — no sub folders — Plogger will assume that these are albums and place them within the first collection in the gallery. Additionally, users can just upload a bunch of images not organized into any folder structure and choose their locations via the web interface. This is a solid choice because you always know that files in the /uploads/ directory are new and need to be added to the database.
Scenario #2: The user uploads files directly into the /images/ directory. This is a much trickier proposition because you are mixing untagged content with pictures that are already in the database. I envision this feature as follows: The user navigates to the import tab. The import page goes through the entire database, checks the entire /images/ subdirectory recursively, and then returns pictures that exist in the file system but not in the database as new items to import. The user then selects where these items should go (the destination will be auto-filled based on the location within the file system). This scenario is more seamless than scenario #1, but also introduces a couple of new problems.
Giving users permission to have direct access to the /images/ folder may give the impression that making changes to the file system will reflect on their galleries. This is very dangerous because changing a folder name, an image name, or an image location in the file system itself will result in a discrepancy between the database entry for the tagged image and the physical image. The database and the file system will be out-of-sync.
A more elegant solution could involve Plogger automatically determining if a file or folder name has been changed — removing entries that no longer exist as files from the database and prompting new or changed pictures as new items to import. IMO, this may be very difficult to implement in code because of the host of new complexities introduced by the problem.
Am I missing an obvious, more elegant solution? Between the two scenarios I have presented, which one would be best? Would you choose the intuitive solution of allowing direct access to the /images/ directory while struggling to keep the database entires in-sync or the current, easy-to-implement solution of simply moving things from the /uploads/ directory with the side-effect of having to recreate subdirectory structures within the /uploads/ directory each time you import? Which one is easier to understand? Does it even matter?

6 Comments
Jump to comment form | comments rss [?]