Feature Proposal: Deprecate Logger::eachEventSince and Func::eachEventSince

Motivation

The LogDispatchContrib is investigating the move to an external logging framework, with support for logging to DBI, Syslog, Win32Events, and many others. It is apparent however that the logging framework does not provide any way to read the logs. And in some cases, it doesn't make sense to read the logs as they might not be on the same server. (remote syslogd for example, or jabber in the extreme case).

Description and Documentation

the Func::eachEventSince() API has limited use:

• Statistics calculation - badly needs a facelift.
• ActivityStreamPlugin
• ContributorsPlugin
• TopicStatsPlugin (not released)
• UserInfoPlugin

There are a couple of possibilities we discussed a bit on IRC

1. Completely deprecate - not implemented in the Log::Dispatch logger
2. Require plain file logging in parallel to any other logging.
   • Log::Dispatch::FileRotate would always be enabled
   • eachEventSince would process the plain file logged
   • Optional methods like DBI or Syslogd would be done in parallel
3. Make plain file logging optional, but required if eachEventSince is needed.
4. Write a separate eachEventSince handler for each supported Log::Dispatch handler when practical. (i.e. not for email, jabber, or Win32Event logging)

This proposal suggestions option 3. eachEventSince will still function but only if the appropriate form of logging is enabled.

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

Sites that chose to not enable plain file logging would get an empty iterator for the eachEventSince function. This proposal is to move Func::eachEventSince() to deprecated status, and document that it's only supported for plain file logging. Document that the current Statistics application is only functional when Plain File logging is enabled.

-- Contributors: GeorgeClark - 08 Aug 2012

Discussion

Note that Log::Dispatch is currently planned as a non-core contrib. It will hopefully work in 1.1.x as well as 1.2. At some future time it might be considered for inclusion in the core. This proposal is to clarify what functions are mandatory for a replacement logger to supply.

Future core proposals might consider changing from the home grown logger API to something more robust like logj4perl.

-- GeorgeClark - 08 Aug 2012

Rather than stubbing eachEventSince if a logger doesn't support it, it might be better to just not implement it. That way callers can trivially use $logger->can('eachEventSince') to determine if it is available.

-- CrawfordCurrie - 08 Aug 2012

Why would we want to deprecate a useful API for a quick and simple Contrib? It seems more useful to code consumers of the logs to cope with the existence or not of this API.

To be honest, when I thought about Log::Dispatch, I was thinking that it would be useful to create Log::Query parallels as needed - not to cripple foswiki due to the lack.

-- SvenDowideit - 09 Aug 2012

It's not the effort to implement eachEventSince, it's that some logging methods probably cannot support a Log Query. After some discussion on IRC, I'm rejecting this proposal. There is no contract that says the core API must be functional. It is perfectly acceptable for a logger to not implement eachEventSince.

-- GeorgeClark - 09 Aug 2012

Just came across this discussion while investigating eachEventSince, i.e. the statistics script, totally blocking the rest of the site while it is running. Also no two requests can write to the plain file logger concurrently. This is a severe bottleneck in the default logging mechanism.

-- MichaelDaum - 15 Jun 2018

Commenting is disabled while not logged in