ntang (ntang) wrote,

  • Music:

Gallery [g]

Ok so I've been pondering things and I think I'm going to rewrite my image gallery script.

For one thing, it sucks. It's a descendant of an old script Brad (you know, LJ-man) wrote and it's totally hacked together. It's hard to configure (well, ok, not that bad), it's nearly impossible to customize (in terms of output, visual appearance, etc.), and uses a brain-dead form of recursion that was me being incredibly lazy.

So why rewrite it? Well, because I can, and because I have ideas how I can improve upon it drastically without having to spend a million years on it. The script's concept is fundamentally sound; it's designed to work on super-low-end machines, as it builds the gallery offline and writes out static files, meaning that even the shittiest machine can have a decent-looking gallery on it without taxing its resources. Since my primary webservers is a 100 MHz pentium (yes, 100 megahertz... the machine you're using to read this is probably, literally, 10 times as powerful - and quite possibly over 20 or 30 times) with 32 megs of ram. But, hey, it works.

So here's what I'm thinking of doing. (This is where it gets even geekier than usual. Comments are appreciated but not necessary. Hell, even reading this isn't necessary at all, I know it'll bore and/or lose most of you.)

- First off, switch to using stylesheets. This'll make all of the basics - color schemes, fonts, etc. easily configurable without needing to edit the script itself. It'd mean "normal" people could change the way the gallery looked, and each gallery could look different just by loading a different stylesheet.

- Secondly, accept both command-line arguments (other than just the directory) and config files (check for a dot-file in each directory before it starts on that directory) so you can customize it at run-time or even on a per-directory basis. It'll still have in-line variables you can set, of course, and it'll default to those, but for people who want more customizability, you can get it. Things like the style sheet, for instance, would be nice to be able to specify on a per-directory basis. Ooh, purty.

- Store an (optional) alias and description of each picture. This is one of those basic image gallery things that every other one does, except for mine. I sort of wish it had it sometimes. Right now you need to come up with descriptive filenames, which seems stupid to me. It's obvious, but obvious is not always better. (In fact, is rarely better.) The only thing I'd need to figure out is how to order and organize and sort the files, esp. in the html output. (More on this in a sec.)

- Of course, for descriptions to be worthwhile, you need an html-page per image, or something where the user can read the description. So that'd have to be an option. Not a problem, though, and that could be configurable in the script (or per directory!).

- Two options for file storage. First off, just make a .thumb or .gallery directory in each directory and store the stuff in there. Advantages: easy as hell to set up, lets you distribute storage across multiple directories (and therefore potentially multiple physical and/or logical devices) pretty easily, and a lot neater than the current method (which just dumps everything into the same directory as the original images). Disadvantages: not centralized, not as efficient (maybe).

- The other option I was thinking of: a centralized storage directory. Store nothing but html and per-directory configs in the main directories; every time you run the script, grab the md5 checksum of each image, and if that image doesn't already exist, create a path and put the image in the centralized data space. Have a link of some sort, probably an empty file named after the md5 sum of the image its placeholding for. Possibly put the image alias in that file. Advantages: allows you to put the same image in multiple places with only a single copy on the disk. Makes it easy to move shit around and clean things up, since all of the thumbnails, descriptions, etc. live with the main image in the central storage. Makes it easy for the machine to deal with the images. Disadvantages: the names are meaningless to the user (just md5 checksums, after all), and it takes processing time to generate all of those md5 sums, and probably more perl modules to manage. It's basically an on-disk database, almost, and may be a bit of overkill.

- The ultimate(ly dorky) way to manage things: build the centralized on-disk "database" based on md5 checksum, and then have meta-data (keywords, basically) for each image. Build the galleries based not on something silly like directories, but based on that meta data. For instance, want to see the family gallery page? Well, load every image with the family keyword in its metadata and display it. This is a cool idea but could be a mess to implement. I'd also have to figure out how to sort and group the images into sub-groups under each heading (for instance, with 1000 family pics, you need to organize them into smaller groups for display or it'll be impossible to browse through). Maybe keywords and sub-keywords, I dunno. This is a nifty idea but might be stupid in the end.

- Of course, the final thing is a cgi or something similar so that it can pull all of the above work out but still do some dynamic rendering. My thought is that if it finds a directory missing thumbnails or with raw images in them (instead of the md5-named empty files) it'll process the images, writing out the thumbnails and everything, and then display it. The advantage is that you can run the script offline to build everything out, but if you're in a rush you can just drop the stuff into a directory. You could even cron it - run the gallery builder a few times a day, say, and if someone views images you've dropped in before the next runtime, it'll dynamically finish the job in that directory only. That way you get the best of both worlds. Maybe even use mod_perl (optionally) and apache modulize it, so it uses the script as a handler for that directory path, anytime anyone loads anything within the /gallery/ directory (for instance) it'll pass it to the script - if everything exists, it can just load and display the index file, otherwise it'll process the directory and then display it. Not sure if I like that, though, as using mod_perl and dynamically determining when to render or not removes a lot of the point of the script in the first place. Still, it'd be a good exercise to learn how to do that sort of thing.

Phew. I know, considering my workload, is putting all of this mental energy into my image gallery script a good thing? Probably not, but I had an urgent need to do some thinking that wasn't work related but still used those "muscles". It happens sometimes.

Anyways, I feel better now that I've unloaded. I think I'll start writing next week, but I need to make some decisions on the issues I listed above. Anyone with any thoughts on the matter, please, chime in. (And bear in mind this is primarily an exercise for myself, so something that only I need or want - or even just that I want to figure out how to do - is a perfectly acceptable reason behind adding a feature. Likewise, if I don't feel like doing something you think it should do, well, tough.)

Update: testing, testing, 1 2 3.

Update 2: FUCK. LJ lost my earlier update, even though I loaded it multiple times in the client and the changes were there each time.

Ok, to sum it up, I think I have some better ideas re: keywords.

Basically, in each directory simply specify which keywords to match on. That gives you flexibility as well as ease of setup, and lets you set up galleries that share photos on multiple subjects and in multiple hierarchies really easily. For instance, I like to post photos of my kids, photos from holidays and other events, etc. With keywords I can easily "cross-post" without having to think about it. It makes organizing pretty easy, too. Add the keywords "halloween" and "2003" and "kids" to a picture and I can easily get it to show up in the events section, the kids section, a by-date section, etc. People can browse by whatever method they want and they'll still see all of the pics, and I won't have to go copying them all around.

With a + or - syntax I can get really fancy... for instance "+halloween +2003 -kids" I can show all of the halloween photos that don't have the kids in them, useful for public-viewing galleries. I guess the "+" can be assumed, actually. Or maybe without the + it'd be an OR instead of an AND. I dunno. Worth thinking about, though, and a different way of managing the photos than most galleries out there, something to actually differentiate it. Hmmm.

Update 3: Something I forgot to mention about the configs is how to handle configs in each directory. Something to consider... does each directory inherit its parents settings, overridden by its local config? Does each directory inherit the root settings, overridden by its local config? Does each directory inherit the inline settings, overridden by its local config? I'm thinking inline -> root -> local, although I may just do inline -> parent -> local (which has the same effect as inline -> root -> local if there's only a config in the root directory, but allows to change an entire directory branch just by changing the root of that specific branch...).
  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded