Rui CarmoI’ve finally taken the time to fix some minor (but annoying) issues with the link-blog layout, one of which was that the thumbnails generated by WebThumb were not properly aligned alongside the item text.
Since I wanted to have them look the same via the site RSS feed and on a number of devices, I ended up wrapping link-blog entries with thumbnails inside a table, which is sure to annoy CSS purists. But sometimes the old ways are best.
While I dealt with that and did some massive search and replaces across the site to fine-tune links and whatnot, and I’ve been mulling the way Yaki stores entries again.
Although I’m perfectly happy with the one-folder-per-entry approach, I’ve been wondering if it wouldn’t be interesting to use “@zipfile@”:Python:zipfile to clump together older content (like, say, all pre-2005 archives) in order to save on disk space – and even then only because current filesystems are crap at dealing with sub-1K files, of which this site has plenty of.
The full-text indexer would still be able to crawl them, they could be extracted on demand for viewing, and I could tune the HTML cache to only keep around the most frequently requested pages. Plus if I did without the cache and served stuff straight up from the compressed archives it would probably be a nice thing for people who, say, are looking for a decent Wiki to pack into a USB stick.
Anyway, I’ve also been revisiting one of my (decade-old?) pet peeves: The way HTML, as a whole, is utter crap when dealing with things like inline images, and the way it is absolutely impossible to have something that does WYSIWYG HTML editing and outputs a single file.
And, again, I’m playing around with Thunderbird and its excellent MIME editor and trying to see if it can be used as an editing interface of sorts. Time will tell if that mini-SMTP server that’s still buried in the Yaki source tree will suddenly start working…