Filemanager obtains comments; overview of my site’s page caching system.

Since I’ve broken my filemanager out of the main Rollator system, it lost a few parts of the integral product which I feel should be there. Every item I write has a small ‘comment’ function associated with it, allowing end users to offer their insights, suggestions, and even just a simple smiley if they find some of my ramblings useful.

As I rewrote the filemanager seperate, I opted to not continue it’s ability for end users to comment with the initial revision. I’ve since re-implemented my universal comment function for the file manager. In doing so, I re-implemented a bit of functionality into my administrative interface that I wrote before I wrote my Apache mod_rewrite rulesets to beautify things.

This function utilized a variable, cryptically called RURI, which stood for ‘Return URI’. This contained the localized server path of the file from whence it was called. This trivial little function allows me to become nearly re-entrant upon data modifications, returning the user to the same place they were before they entered their comment.

Aside from being elegant in that the end user does not have to contend with any ‘beneath the hood’ sections of the software, they are able to instantly see their entry. Usually.

Due to the volatile nature of my software, and the front page, I have to do what I can to minimize system impact. These two sections of my site are those ‘hardest hit’, and thus, I have opted to implement caching for both of them.

The practical upshot is that these pages load almost instantly, and the server does not get bogged down with the few SQL calls used to popualte my variables. Of course, it does not make sense to ‘break cache’ when a user enters a comment, so there is a small delay between the users entering a comment on one of these pseudo-static pages, and when it actually shows up upon a rendered page. I’ll investigate a means to update the ‘static’ section of the pages, whilst leaving the comment section dynamic, as that is it’s nature.

This is certainly going to be an interesting task, as the way I cache the page is horribly simple. Feel free to skip the rest, as what follows is a horribly geeky commentary—unless you enjoy that sort of thing.

What I do is create a hook before the page renders, populate and recurse through my data, saving all of this to an overloaded variable. Then, I compress this data with zlib, and store it in it’s own table, with a hash for a reference. I pass this as an E-Tag to the browser, which then uses this for it’s own information. When the browser presents it’s E-Tag, Rollator checks this E-Tag prior to rendering, and if it matches one in the cache, it presents the cache, decompressing on the fly as need be.

So, I need to discern a more appropriate way of caching data, rather than creating the whole page pseudo-statically, or, a more optimal way of parsing and proffering comments. I know which will be more challenging, and hopefully, more rewarding.