January 2006 Update
It’s easy for me to see Fyre as a ‘dead’ project these days- the existing codebase was declared ‘done’, and we moved on to a new architecture dubbed Fyre 2.0. In some ways this rewrite has suffered from second system effect, and the code hasn’t been touched in a while. But, I think we all agreed this was necessary. Fyre 1.0 really was a great release, and it really did everything we felt it should do considering the project’s scope.
Anyway, it’s really heartwarming when I come across an enthusiastic user of Fyre on the interweb, who’s posted some renderings of their own. It’s even cooler to find someone who’s implemented their own Distributed Chaotic Image Renderer after being inspired by Fyre.
My traditional method of playing DVDs at home would be to boot up my HTPC and play them via Freevo. In concept this was great, but the picture quality left much to be desired- lots of horizontal ‘wiggle’ due to noisy sync signals from my video card’s component out, and the video was getting scaled at least twice.
Yesterday, while wandering the shopping megaplex that is Santana Row, I finally picked up a hardware DVD player: An LG LDA-511, on sale for $110 after rebate. I’m just blown away by how much hardware you get for that price these days: slot loading drive, HDMI output, upscaling to any HDTV resolution, DivX/MPEG4/JPEG/MP3/WMA playback, memory card slots… The picture quality is great, and it will even play a lot of music and video directly off of my existing DVD-R discs. My one complaint so far is that the memory card reader is excruciatingly slow. It’s a good thing I doubt I’ll ever have a use for that feature.
I came across the Django project recently. This is an incredibly spiffy mod_python-friendly web framework, which includes a template system and a rather cute object-relational mapper. Since I’ve been wanting to get CIA‘s web frontend away from Twisted and onto mod_python for a while now, this looks like a great opportunity to simultaneously do away with Nouvelle.
So, I’ve started a branch for what’s sure to be a heavy-handed hack and slash partial rewrite. The biggest issue with splitting the HTTP frontend into multiple mod_python processes, however, is the ruleset storage. Currently, CIA just loads all rulesets from the database on startup, compiles them a bit, then scans them linearly every time a message is delivered. This is both RAM-hungry (about 8MB) and very CPU inefficient. My current strategy is to actually compile the rulesets into an SQL table such that the slowest and least scalable aspects of message filtering can all be done efficiently within the SQL server.