Therefore 13% of all hits are people checking for new changes.
So either we're all bored or theres a demonstrable need for effective notification. Yes I know, I was supposed to be looking at that too.
d.
It turns out if you build a event driven mail based notification system you shortly there after discover that it's too painful to use. The Wiki model results in editors writing changes so they can preview; and in tangles of nodes going thru periods of total chaos[1] as an editor attempts to make any changes that involve more than one node. Both these make the change stream very hard to read. I suspect that much of that could be resolved by sending mail with changes "when the dust settles". I've used a similar model to trigger an automated build. When a change comes in scheduling an "at" job to do the build in ten minutes (canceling any currently scheduled build as I do that). Then the build would take off 10 minutes after the last passenger got on the plane. Something similar might be the best thing for the Wiki.
The routine that computes the diff is GetKeptDiff. It depends on it's user having extablished dynamic extent in ways that make your brain hurt. It appears that the heart of that is done by invoking OpenKeptRevisions, with it's bogus argument. That loads the data needed to do the diff (the mimic of an RCS ,v file kept in the "keep" directory). It is probably easiest to just grab those files directly. You'd probably have to bump up KeepDays as well.
- ben
[1] It's though provoking to consider overlaying a XMLRPC or similar API so editors could create a private sandbox for doing real editing... did anybody mention that CMS is rat hole?
