History

2011-11-30 - Meeting notes

Participants: Karsten Dambekalns, Steffen Gebert, Steffen Müller, Ingo Renner

Karsten's Opinion

Karsten is joining our meetings in order to exchange ideas between TYPO3v4 and FLOW3 and find a solution, which helps to implement Logging in v4 and FLOW3 similar to each other.

His thoughts on our previous meeting's notes are:
  • Severity constants: We should use PHP's LOG_* constants instead of introducing own ones (which follow the syslog RFC)
    • No consensus, yet - would be no big deal to change it
  • Record object: Do not use t3lib_log_Record. This is used internally and passed from the Logger to the Writer, which then logs it to database etc. The user of the logging API does not get in touch with this object, but we decided before to not pass arrays around. In Karsten's opinion using such a value object only causes overhead, and FLOW3 currently has methods with some parameters (message, title, severity, etc.).
    • After Karsten left, we discussed this again and agreed to keep this. E.g. with the FingersCrossedWriter:https://github.com/Seldaek/monolog/blob/master/src/Monolog/Handler/FingersCrossedHandler.php could just queue up all these Record object.
  • Performance: Karsten mentioned that we should keep performance in mind. For example in varnish the logging itself is a bottleneck. We came to the conclusion that in case of TYPO3 the new logging API overhead probably won't have a significant impact on the performance.
  • Best pratices: Karsten mentioned the logger backend in Apache chainsaw and the processors in monolog as clever examples. Ingo dived into java.util.logging and also found some good practices.

General Discussion

It turns out that the whole project probably needs more time to be spent on discussions compared to coding. Finding a perfect concept is very hard, esp. when it comes to the "context" (see last meeting - e.g. for whom would a log entry be of interest? for a developer, for an administrator, for an editor?).
Therefore we decide to keep the weekly meetings, to not only synchronize each other (who e.g. had no time to look at the code the last days) and discuss previous and future work.

Identification and classification of events

We discussed the problem of how to manage identification and classification of events as a basis for clever filters in the view. Consens was that we should not loose too much time on discussing solutions for theoretical problems, which are far from practice of TYPO3 community.

Reuse vidi (new list compontent) for the log module

The idea is to reuse the vidi list component when creating the new log module for the TYPO3 backend.

Steffen M. mailed with Fabien Udriot, who is working on vidi, a new list component for the BE. The actual status of this project is:
"The project will landed in 4.7 in a preliminary state for the needs of "files" firstly. It means it will be adapted for listing files (the replacement as the current file list) and not be versatile to displayed any kind of records. However, the situation should evolve for 4.8 where the list module will be more powerful."

The vidi project is located here:

Resources we have discussed

FLOW3 Log Configuration:

FLOW3 Log Implementation:

t3lib_log_Record

Apache chainsaw:

java.util.logging