TYPO3 Core

Several tasks have been opened to clear various tables (cache, etc.). Why not trying to make it more general. I wrote an extension called "cachecleaner" which is designed to clean up arbitrary tables. It works as part of the CLI lowlevel cleaner for now, but could be adapted into a Scheduler task (I've been meaning to do that for a long time, actually).

http://typo3.org/extensions/repository/view/cachecleaner/current/

Patch set 1 of change Id7c58d28e4f6e82a708513a3ce9761baf36c06cd has been pushed to the review server.
It is available at http://review.typo3.org/1376

Pushed a patch for EXT:scheduler implementing the garbage collection as a scheduler task. The task deletes all database entries in sys_log table older than n days, which can be set by an additinonal field.

Patch set 2 of change Id7c58d28e4f6e82a708513a3ce9761baf36c06cd has been pushed to the review server.
It is available at http://review.typo3.org/1376

Patch set 3 of change Id7c58d28e4f6e82a708513a3ce9761baf36c06cd has been pushed to the review server.
It is available at http://review.typo3.org/1376

Patch set 4 of change Id7c58d28e4f6e82a708513a3ce9761baf36c06cd has been pushed to the review server.
It is available at http://review.typo3.org/1376

Patch set 4 is a revised version that handles more than just the sys_log table:

To prevent administrators from committing hazard to the database, tables that can be cleaned up must be registered in an own 'option' array (which extensions can add entries to). There a specific table and a time stamp field must be defined, the table will then be selectable in the task as additional field.

Per task only one table can be selected, there is no multi-select-option to simplify the logic a bit if configured tables 'vanish' from configuration if extensions are un-installed or configured otherwise (the according task will then throw an exception).

For the core tables: Currently only sys_log is configured as default table to be chosen. The following tables are candidates to be added to the configuration: sys_history, be_sessions, fe_sessions, fe_session_data. All of them already have some weird internal garbage collection implemented in the core, so that they are already garbage collected during fe/be calls sometimes. This could be cleaned up in an additional patch, which should add a registry handling to the garbage collection task that logs its last execution and only calls the currently built in core garbage collection if our new task did not run for a long time. Since there is no handling for this currently, I've not added those tables to the task, yet.

Patch set 5 of change Id7c58d28e4f6e82a708513a3ce9761baf36c06cd has been pushed to the review server.
It is available at http://review.typo3.org/1376

Patch set 6 of change Id7c58d28e4f6e82a708513a3ce9761baf36c06cd has been pushed to the review server.
It is available at http://review.typo3.org/1376

Patch set 7 of change Id7c58d28e4f6e82a708513a3ce9761baf36c06cd has been pushed to the review server.
It is available at http://review.typo3.org/1376

Patch set 8 of change Id7c58d28e4f6e82a708513a3ce9761baf36c06cd has been pushed to the review server.
It is available at http://review.typo3.org/1376

Patch set 9 of change Id7c58d28e4f6e82a708513a3ce9761baf36c06cd has been pushed to the review server.
It is available at http://review.typo3.org/1376