Any thoughts on implementing the Psr\LoggerInterface?

Would be great if we'd implement: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md

How is logging to the database handled now? We currently have four database tables for logging: _logger_message, _logger_exception, _logger_api_call, _logger_error - could we simply merge these tables into a single one with a type field? This layout is mainly influenced by the way ZF1 handled logging.

Re Psr\LoggerInterface:

Is there any tangible benefit that implementing LoggerInterface would provide Piwik core developers and Piwik plugin developers?

@halfdan

We currently have four database tables for logging: _logger_message, _logger_exception, _logger_api_call, _logger_error - could we simply merge these tables into a single one with a type field?

This is part of what my pull request does.

Using PSR3, theoretically, would make it easier for enterprises to swap out our logger for something else. For example, monolog has handlers for AMQP and NewRelic.

So it would be easier for Piwik users to use logger backends that Piwik doesn't provide? I think that's something for @mattab to think about.

sounds interesting, but it's not MVP for the Log rewrite

@diosmosis Very cool!

Would it be difficult to implement PSR3? The closer we get to the PSR standards the better IMHO.

Would it be difficult to implement PSR3? The closer we get to the PSR standards the better IMHO.

Do you have any reasons for that? Using the PSR implementation would mean more code for the logger, more code for users of the logger, and more code for anything that should be "capable" of logging. We could easily add an event to allow plugins to provide new writers and a plugin could provide the PSR3 adapter itself.