Flash charting - not too flashy

Original Webalizer PNG graphs became quite small when viewed on a high-resolution screen, which is pretty much any screen nowadays and are not very easy to work on due to a lack of a layout engine. Poor antialiasing in the underlying GD library does not help quality either. Being able to produce better graphs was one of the reasons I added XML reports to Stone Steps Webalizer. Last couple of months I was mostly working on making sure that it's easy to use XSL templates that will be included into the Stone Steps Webalizer package with various Flash charting packages.

Waiving a type-safe flag

Sometimes C++ enum's are used to define bit flags, such as read/write attributes, which can provide better type checking at compile time. However, when performing bitwise operations on enum values, one has to cast resulting int's back to enum's, which bypasses strict type checking and makes enum definitions somewhat pointless.

I asked for a count, not a life story!

One of the main reasons I switched the state file to use Berkeley DB was to allow Stone Steps Webalizer generate reports without loading the entire monthly data set into memory, which may be hundreds of megabytes in size for high traffic web sites and proxies. Once this was implemented, report generators just had to open the database and traverse a few records at the top of each table, such as hosts or URLs, in order to generate a relevant report, which took almost no time. Soon, however, I noticed that generating top-x reports using a 600+ MB database takes minutes and so much memory, as if the entire database was being read.