Feature Proposal: Plugin hook for TWiki::writeLog

Motivation

Want to implement a plugin, which calculates various statistics based on logs. Therefore need log data in a SQL backend.

Description and Documentation

Let plugins write their own log "files" (ie. put log data additionally into a database).

The alternative is to implement various plugin handlers (aftersaveshandler, afteredithandler, ...) to collect log data "manually".That way you still miss all "search" actions.

Examples

Impact

Implementation

logHandler( $action, $webTopic, $extra, $user, $remoteAddr )

-- Contributors: OliverKrueger - 09 Oct 2008

Discussion

Excellent idea. But simply logging is not sufficient - you need to define an API for recovering log information, otherwise it is a "write only database" for plugins etc. See the interface I defined for the "changes" log as an example of how this could be done. It would make sense to rationalise the logging features to combine changes, log and debug log (select which "log" to write to using an enumerated type on the writeLog call)

-- CrawfordCurrie - 10 Oct 2008

This feature request is lean. I just want to add a hook. The rest (definition of an API etc) should be up to a Contrib or Plugin.

-- OliverKrueger - 19 Oct 2008

Crawford is right, this stuff needs to be symetrical - which shows it shouldn't be a Plugin handler, rather a TWiki::Log class that has reader and writer methods. Thus abstracting the log implementation from all plugins that might want access to the data. That API would then be exposed in TWiki::Func.

Lean-ness doesn't over-ride the long term needs, and in this case, If we can refactor the TWiki log code to be pluggable using a standard CPAN Log API, we'd be much better off.

for eg Log::Log4Perl, [Log::Handler (although I don't see readers in these :/)

before the no-more-CPAN people start - I am not saying we should require the advanced cpan logger, just hat we should use one's API so it can be plugged in as an advanced replacement. We've always known we need industrial strength logging, such as being able to turn on a debug log mode, just have not gotten around to it.

-- SvenDowideit - 19 Oct 2008

A few questions:

Is this accepted by the 14-day-rule or does it need the next monday meeting following the 14 days?

If it is accepted: Is this a mandate to investigate more on log handlers in general (proposed by Sven) or is it a mandate to go on with the most simple solution I had in mind when I proposed this feature? (I am not sure, if I am experienced enough and have enough of time to go for the big solution.)

-- OliverKrueger - 26 Oct 2008

Concerns have been raised against the basic proposal, so it has to be discussed. The problem is if you don't plan ahead, then some other poor sod is going to face a hell of a problem to do it properly later. So it's better to make sure all the basic concerns are considered and factored in up front, rather than just hacking in the first solution that comes to mind.

I have been reflecting on this. While I think there is a need for a pluggable logger implementation, the reality is that there is a more immediate requirement for multiple loggers, and the easiest way to handle this is by providing a plugin handler as you describe. I don't think that handler precludes the pluggable implementation in any way; it is independent of how it is implemented in the core. So I think you should go ahead with the simple impl.

-- CrawfordCurrie - 27 Oct 2008

Decided at HelsinkiReleaseMeeting2009x04x20 to park this proposal until owner found and spec defined.

-- PeterThoeny - 2009-04-20