Experience tells me there is lot of redundant work done in the name of stats, yet when I really need them, I either end up back in the log files in Vi, or just can’t find what I need succinctly, wading through screeen after screen of graphs.

From a developer POV I really only look at logs when an exception is identified, lots of hits from a particular IP, massive ramp up on requests to a page that normally has few hits. I want to filter out all the images hits etc.

I want it to contact me in the manner I require when an exception I have programmed into it happens.
For my clients I will want different things, I have set up I don’t know how many stats procedures using analog, webtrends etc, the fact is that busy people just aren’t that interested in stats per se, they want the headlines sent to them when there is something worth telling them. THEN they want to drill down/through to glean some supposed “fact”.

I guess this means the api might start to look like:

setResetFrequency(daterange);
setAlertType(“text”, 007712345678);
getTopRequests(daterange, count, [directory]);
setIpCountTrigger(daterange, 100)->setAlertType(“email”,”me@this.com”);

Is that the kind of thing you want to write unit tests for?

A good example is local elections, it only happens every 4 years. nobody is interested in them at all, yet for a week prior, during and a week after, everyone wants to know who was looking at a particular results and why.

So, I’d like to add to my CMS a couple of lines like;

$counts = new stats( daterange, “/logfile/[pattern]“);

echo ‘Between ‘ . daterange[0] . ‘ and ‘ . daterange[1] . ‘ this page has been requested ‘ . $counts->page($_SERVER['PHP_SELF']) . ‘ times’ ;

I rather like the idea of stats appearing on webpages as meta data, I like the immediacy and relevance, it also provides a parallel means of navigation, which I am into.

SQL, do you mean as in SQLite? Is that instead of a cache?

How about stipulating PHP 5 +, and using APC instead of/as well as a database? Or then again using SQLite’s in mem cache.