Talk:Logging 2: Difference between revisions
From MoodleDocs
sam marshall (talk | contribs) Created page with "Basically what's in here looks fine to me. I wrote a proposal Logging API proposal which includes some of these changes as a single development chunk, and should not cause pr..." |
No edit summary |
||
| Line 2: | Line 2: | ||
[[User:sam marshall|sam marshall]] 19:40, 12 February 2013 (WST) | [[User:sam marshall|sam marshall]] 19:40, 12 February 2013 (WST) | ||
=== Summary: Events/Logging API 2.6 === | |||
Logging is implemented in form of event-listening by plugins. | |||
Plugins listening to the events may be: | |||
* generic logging plugin implementing interface allowing other plugins to query information | |||
* reporting plugin that aggregates only information that it needs and stores it optimised for its queries | |||
Our tasks: | |||
# Events API must ensure that everything that potentially may be interesting to the plugins is included in event data (but does not query extra data). There should be as fast as possible to get the list of listeners to notify: Moodle -> Logs | |||
# Logging API is the form of plugins communication to the generic logging systems. It might not be extra effective but it stores and allows to retrieve everything that happens: Logs -> Moodle | |||
# We make sure that everything that is logged/evented now continues to do so + log much more | |||
# Create at least one plugin for generic logging | |||
[[User:Marina Glancy|Marina Glancy]] 13:05, 15 May 2013 (WST) | |||
Revision as of 05:05, 15 May 2013
Basically what's in here looks fine to me. I wrote a proposal Logging API proposal which includes some of these changes as a single development chunk, and should not cause problems for others implementing the rest of it later. The main focus of my proposal is providing the option to move logs out of the database (because the number of database writes is probably Moodle's single worst performance characteristic) but it should help enable the other enhancements from this proposal as well, in future.
Sam marshall 19:40, 12 February 2013 (WST)
Summary: Events/Logging API 2.6
Logging is implemented in form of event-listening by plugins. Plugins listening to the events may be:
- generic logging plugin implementing interface allowing other plugins to query information
- reporting plugin that aggregates only information that it needs and stores it optimised for its queries
Our tasks:
- Events API must ensure that everything that potentially may be interesting to the plugins is included in event data (but does not query extra data). There should be as fast as possible to get the list of listeners to notify: Moodle -> Logs
- Logging API is the form of plugins communication to the generic logging systems. It might not be extra effective but it stores and allows to retrieve everything that happens: Logs -> Moodle
- We make sure that everything that is logged/evented now continues to do so + log much more
- Create at least one plugin for generic logging
Marina Glancy 13:05, 15 May 2013 (WST)
