[PEAK] Anybody using peak.running.logs or peak.running.timers?

[Phillip J. Eby]

If you are, please let me know what level of customization/use you're 
doing.  Are you using the logs.Event class or any of its features?  Custom 
logger objects?  Are you doing anything more complex than defining a few 
loggers in an .ini file?  Are you using peak.running.timers at all?

I'd like to know because my current intent is to completely remove 
peak.running.timers, and I'm considering an overhaul of peak.running.logs 
as well.

I mainly intend to change the *implementation* of the logging system, 
rather than its interfaces, though.  The principal interface I'd expect to 
change is ILoggingService, which would add a method for publishing a log 
event, similar to the 'IBasicLogger.log()' method, but with a couple of 
additional parameters.  The loggers provided by the logging service would 
actually be thin wrappers over this additional method, to specify the 
originating component and logging category.  The method would then be 
implemented as a generic function.

For backward compatibility, I'm thinking I would retain the existing 
logging mechanisms through the a4 release, but allow them to be overridden 
by configuration with the logging service.  That is, if no "new-style" 
configuration rule matched the intended log output, the "old-style" logger 
would be given the data.

The part I haven't figured out yet is how "new-style" configuration would 
be done.  From code it's quite easy using 'before()/after()/when()' calls, 
but I haven't yet decided on a sensible syntax for doing it from .ini 
files.  (In general, adding generic function methods from .ini files is an 
as-yet-unexplored art.)

I'd rather not have to go to ZConfig just to configure loggers, but before 
we had generic functions that was on my list to be done anyway.  Generic 
functions would just simplify the format, since it wouldn't be necessary to 
make the file format mimic the structure of log processing.  (I.e., no need 
to manually design a decision tree in nested ZConfig blocks, just make a 
bunch of <Rule> entries.)

Here's what I think I'll do...  keep the existing configuration mechanism 
for simple configuration, even beyond a4.  It's simple, it's easy, it 
works.  For more complex stuff, we'll use "plugins" that can be configured 
in Python, ZConfig, or any other format one chooses to create.

The ZConfig format would probably look something like:

     <Format feed_format>
     something something
     </Format>

     <LogFile feed_log>
     Filename $somewhere/feed.log
     Format feed_format
     </LogFile>

     <Rule Feeds>
     when category in 'xyz.*' and level >= INFO
     sendTo feed_log
     </Rule>

In other words, you could define formats such as syslog format, Apache 
format, etc., define log files and other output mechanisms, and then 
specify rules that indicate when output should be sent to those output 
mechanisms.  The above is more of an expanded example; more likely the 
short form would be rendered thus:

     <LogFile feed_log>
     Filename $somewhere/feed.log
     Format syslog
     When category in 'xyz.*' and level >= INFO
     </LogFile>

Additional rules could still send outputs to 'feed_log'.  Rules and outputs 
are allowed multiple 'when' clauses, and rules can also specify multiple 
'sendTo' clauses.  'when' rules would get access to all the relevant 
parameters from the method being invoked, so you could actually specify a 
rule that looks for a keyword in the log message, for example.

Of course 'LogFile' would be just one option for sending output.  One could 
potentially define e.g. a 'Mailer' output mechanism, automatically sending 
error messages via email.  (In practice, I think I'd wait on defining such 
a thing until we have some sort of IMailService to attach it to, rather 
than defining a bunch of mailing options just for logging, but the idea 
makes a nice example illustrating what kinds of outputs would be nice to have.)

Anyway...  your feedback on these ideas and issues is appreciated.