Advertise here: Contact FM.
I'd love to do this all, just not as active queries on the database for every request.The way I do it is one query per hour per unique requested thread. So, if ten people request the same thread, the file is cached on the first request and fetched once an hour for thirty days. That's still 720 page views over 30 days, but every member can view the RSS without taxing the database.
must create a caching mechanism so that if user A requests the feed in her reader and user B comes along 30 seconds later to do the same, the same flat file is sent to B, off the filesystem, if the contents of the feed haven't changedThat's exactly what this does, except in perl. It's yours if you want it.
how to determine if there's new info with as little cycles as possibleA last modified date associated with each thread would do the trick, then you can tell if a new file needs to be created in one DB query.
Do you: create a flat file anytime a tag, comment, or user does anything?I do it every hour. You could do it every n minutes. n could be user dependant or global.
lots of writing files to the db that might not be used by anyoneI write the files to the filesystem, saves resources all around. I use a a directory structure that is based on the site name and the thread number. This keeps too many files from building up in one directory.
and please refrain from the kneejerk "but PHP/perl/rubyonrails/BASIC" could do it so much easier!!!1!!!"I'm not saying anything could do it easier than anything else. It's just done in perl.
XML::RSS currently supports 0.9, 0.91, and 1.0 versions of RSS.
and I'd like it not to slow the server down.
posted by bonaldi at 4:04 PM on April 8, 2005