Future major features

The log-in related information should be IMHO stored in a separate table.

SQL queries are the only fast way to access data in our PHP code, so yes if storage plugin wants to make data available in standard reports it needs to expose it as a standardised table view.

The new design allows you to write add-ons at different levels:
* reports - using SQL interface to fetch or aggregate data
* storage plugins - read/write entry point for event data
* custom storage manager with custom readers and writers
* any custom logging solution based on simple event observer

The goal is to capture more structured data and to allow more customisations in all parts of the logging and reporting process. Do not expect any major changes in the standard distribution now because the first step is to cover the same functionality compared to 2.5. Do not expect performance improvements in standard installation either, however admins should have more ways to tune their servers to handle the increasing amounts of logged data and developers may create some novel solutions for specific use cases.

Two more problems from wiki, "Existing problems" section:

• Logging is added ad-hoc by developers and has spotty coverage.
• Some logged actions do not contain important information needed later.

New framework won't help for #1 - logging will still need to be added ad-hoc by developers. To fix this, we would need to think about front-end controller that does the logging without having a need for developer to implement that explicitly.

The same goes for #2 above - we need more data passed not the new framework.

As for:

• log tables are joined in many popular queries and are slow

This can easily be fixed without complete rewrite as well - it'd be enough to log as we do now and also trigger an event.

So - what are existing issues with logging at the moment? I don't think we need a complete rewrite and new architecture to solve issues listed in http://docs.moodle.org/dev/Logging_2#Existing_problems . By creating whole new logging layer we are:

• reducing reliability (introducing new bugs, new layer, more components)
• introducing more complexity (logging is dead simple now, does it have to be complex?)
• decreasing performance (direct write to table  vs event -> observer/listener -> write to table)
• creating more work just to catch up with the existing features
• at the end of that phase we will have no added value (as there will be no other logging plugins)

I would think about what really is important and implement just that, for example:

• events seem like a great idea, maybe just trigger an event after we do a normal write to DB? If anyone needs to consume logging event, then even creating local plugin may be OK, do we really need more interfaces? Look at messaging plugins for example - nobody is really using them and that has added more complexity into Moodle
• structuring log data is again a great idea - we can do it already without complete rewrite (e.g. add more columns to mdl_log)
• we need to tackle SQL joins on mdl_log no matter what - so let's do it now and then think about the rewrite. Maybe we should put some data (like logins) into a separate table, as suggested by Petr?

In general, I would suggest to first see what we need and then create a framework/layer for our needs, instead of doing the opposite - creating architecture that we may need in the future.

Tomek