Lire should offer an API to a persistent store which could be used by all components to store and retrieve parts of data.

The current archive implementation is used for two purposes. First, it is used for inter-components communication during one jobs life-time and it's also used for long-term storage. The first part should be moved to a control file mechanism like the one described in the message PROPOSAL: New Online Responder Architecture to the <development@logreport.org> mailing list. The second functionality is the proper domain of the persistent store API.

The persistent store should also be arranged around the user/server hierarchy described in the configuration framework proposal. meaningful for the reader, the information contained in the XML reports produced by Lire should be modified to contain other information like labels, ratio information, overall statistics, etc.

Currently, the analysers that produce the derived schema and extended schema DLF data work in the report generation process. Those should be moved into a separate process between the log normalisation process and the report generation process. This would permit some optimisations in the data format and is necessary to support other report generation backends.

Standard internationalisation components like framework. The XML components should also be modified to support other charsets than basic ASCII.

Altough the Lire framework is meant to be extended and there is already several APIs provided to do so, most components are still statically registered. For example, each new superservice and service must be registered in several static lists. Same things for the output formats. It would be better if those lists could be built dynamically and if we would provide simple tools to register new components (something like a lire-install command).

To make the Lire framework usable in more context, it might be worthwile to reimplement the APIs in C so that mapping for other languages than perl could be made available. This would also make it possible to support lex/yacc based DLF converters. It could also help performance.