Forum OpenACS Q&A: Re: Top Ten Priorities for OpenACS ... what are yours?
Smarter logging. What I'd like to see is:
each and every package has a loglevel and a show-boot-messages parameter. Boot messages are either shown or not, log messages are filtered based on the level set for the package. The current system spits out so much information that I rarely bother to look at it. When I do suspect a problem, I contrive a test scenario, flush the log, and restart anyway - mainly because there's too much in the logs to figure out what's wrong.
The logger system would have to know that it was finished booting.
Having done that, run through the packages and stratify based on actual severity - Notice/Warning/Error.
I'd like to keep it set to a Warn/Error level when things are going OK and crank it up when there's a problem.
A system setting (acs-kernel?) can override the above for the entire system.
to dynamically generate meaningfull log reports based on some user specific parameters?
I read the paper (quickly) and here are my thoughts:
1. I was referring to the "error" logs, rather than the access logs.
2. Most sites don't bother with realtime reporting on access logs, rather, they roll them daily and run report software against them (largely due to size). While this would allow a means of providing realtime logs, the bloated size of already overlarge log files would be too much. I'd rather see them go the other way - normalize the acccess data.
3. If we converted the access logs to XML then only one piece of software could read them. Currently there are at least dozens of good packages out there to do whatever reporting people want.
4. I can code XML but not XSLT.
5. I don't have a personal need / desire to see it happen.