[TransWarp] LOG_* will disappear; running.logs changes

[Phillip J. Eby]

FYI, the LOG_* functions from peak.api will be going away, perhaps as early 
as this weekend.

After a few interesting discussions on the subject, :) Ty and I have 
arrived at an architecture for peak.running.logs.  From a usage point of 
view, it will be very similar to the PEP 282 'logging' package.  However, 
in keeping with our emerging philosophy of PEAK "works with X, but does not 
require it", 'peak.running.logs' will be able to work with 'logging', but 
will not require it to be installed, and our configuration architecture for 
logging will be quite different.

Here's how it'll work.  We'll define an interface, 'running.ILogger' that 
represents the methods available on PEP 282 loggers.  (We may also have an 
'IPEAKLogger' that adds more functionality, but that's not yet clear.)

How you get loggers will be up to you.  PEAK's internal approach will be to 
use bindings to properties under a 'peak.logs' namespace, e.g.:

class aThing(binding.Component):

     logger = binding.bindToProperty('peak.logs.path.to.logger')

     def foo(self):
         self.logger.debug("running 'foo' method")

For use with the 'logging' package, there will be a 'logging.logger:' URL 
scheme that gets the appropriate PEP 282 logger, e.g.:

     logger = binding.bindTo('logging.logger:path.to.logger')

Of course, if you want to direct a PEAK logs to a PEP 282 logger, you can 
do this in a PEAK .ini file:

[peak.logs]
path.to.logger = naming.lookup(forObj, 'logging.logger:path.to.logger')

There will also be URL schemes for PEAK built-in logger types (e.g. 
LogFile), so you can also simply do this:

[peak.logs]
path.to.logger = naming.lookup(forObj, 'logfile:/path/to/logfile')

You'll of course also be able to specify wildcards:

[peak.logs]
anything.under.this.* = naming.lookup(forObj, 'logfile:/path/to/logfile')


PEAK will not attempt to compete with PEP 282's wide array of handlers, 
formatters, filters, etc.  If you want that sort of thing, use the 
'logging' package and then use 'bindTo("logging.logger:foo.bar")' to hook 
up your components to it.  The main PEAK logging component, LogFile, will 
be a combination logger/handler/formatter/filter with the only options 
being its log level and destination.

Keep in mind that if you directly use the logging package, it will not be 
possible to integrate your components in the same app server with a 
component that wants to configure the logging package differently.  For 
this reason, you should *always* configure  PEP 282 loggers by accessing 
them via the 'logging.logger:' URL namespace.  In this way, an application 
server could provide a different logging namespace to each application, 
based on the PEP 282 implementation's classes.

We believe this architecture is good STASCTAP (Simple Things Are Simple, 
Complex Things Are Possible), while the PEP 282 implementation tends to 
make even simple things complex.  For simple things, we will point loggers 
to files via configuration properties.  For complex things, we may use PEP 
282 loggers.  You, of course, will be able to take your pick, according to 
what you find most useful.