Howard wrote:
I remember noticing various comments on the list bemoaning the lack of some sort of counter. I also remember noticing the objections which were raised, and why counters weren't feasible. I don't remember reading these objections, which may be why when I found a need for a counter, I sat down and wrote one. I now have a working Counter product which provides a <!--#counter--><!--#/counter--> tag .
I'll indicate my appreciation of your contribution by, well, asking for more! :^) One of the big objections of the counter kind of object is that the object database gets bigger on every request. A good workaround for this would be to cache writes to the database. Thus, imagine a counter that: 1) Only wrote to the database after a threshold had passed. For instance, only every tenth state change or not until ten minutes had elapsed since the last write. 2) If the process was nicely shut down, the object would save itself. 3) Had knobs in the management screen that allowed adjusting the "buffered write" policy. The benefits: 1) The database wouldn't keep versioning into oblivion. 2) The application wouldn't be slowed by writes on every request. The drawbacks: 1) If the process exited not nicely, some state changes would be lost. --Paul
participants (1)
-
Paul Everitt