Lire 2.0 will get released early March 2003.
Status: Usable, not yet fully integrated
Responsible: Wessel Dankers
Prerequisites: None
Est. Man-hours: 60
Lire's framework should contain a configuration API that should be used by all of its components. See the messages PROPOSAL: Lire Configuration Framework and PROPOSAL: Configuration Framework and Extensibility to the <development@logreport.org> mailing list for more details.
The library code for the new Configuration API is in CVS, but it's not yet fully integrated with the rest: everywhere Lire uses configuration variables, it should use the new API. It can do all the parsing and group stuff now.
Integration is being done in a way that provides enough in "backward compatibility" to offer a migration path for our users' configuration while also minizing the changes needed to our source tree. Like for the DLF API scenario, we will be able to release even if the whole source tree isn't converted to the new API yet.
The configuration API integration roadmap looks like the following:
Write a tool lr_env2conf which exports the environment-based configuration to the XML file format. (Migration tool for our users' configuration).
Write a perl module Lire::Config::Legacy which exports the XML-based configuration to the old environment variables. (Makes it possible to use the new API from the perl code which uses the old API.)
Write a tool lr_environment which exports the XML-based configuration to the old environment variables. (Makes it possible to use the new API from the shell scripts while minizing the required changes). This tool should replace the old lr_env tool.
Make sure that the API makes it easy for Lire's extensions (DLF converters, analysers, etc.) to add configuration parameters.
Rewrite lr_config to take advantage of the new API features.
Document the public part of the API.
Modify exising code to use the new API.
Items 1, 2 and 3 must be completed for a release to happen. Items 4 and 5 add new features which are really desirable, but we can cut there in the worst scenario.
Status: Implemented in simple form
Responsible: Joost van Baal e.a.
Prerequisites: Section , “Configuration API”
Est. Man-hours: 60
Lire should offer an API to a persistent store which could be used by all components to store and retrieve parts of data.
A start of a storage API (Lire::DlfStore) is implemented, which is adequate for now; we can improve on it as needs arise.
The old archive implementation is used for two purposes. It is used for both inter-components communication during one jobs life-time and 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, Lire::DlfStore.
The persistent store should also be arranged around the user/server hierarchy described in the configuration framework proposal.
See also Francis's message PROPOSAL: Datastore oriented mode of operation to the <development@logreport.org> mailing list.
Status: Started
Responsible: None
Prerequisites: Section , “Configuration API”, Section , “Storage API”
Est. Man-hours: 20
Although the current distribution supports merging of reports, it should be better integrated in the lr_cron and lr_config interfaces.
Status: Implemented, not yet fully integrated
Responsible: Francis J. Lacoste
Prerequisites: Section , “Storage API”
Est. Man-hours: 80
The DLF Converter API is complete and tested. What is left is integration in the lr_dlf2xml pipeline, as well as writing documentation and porting the convertors.
Not all convertors are planned to get converted to use this new API. Since backward compatibility with the old interface is part of the new API, this won't cause any problems. Backwards compatibility is offered via the Lire::OldDlfAdapter module, which translates the old API into the new one. This choice is made because migrating all convertors before the 2.0 release would take time, be risky and wouldn't give much benefit. One convertor will get ported, and examples will be written on how to port and use the new API, in order to gain mindshare.
When bugs are found in old convertors, or extra features are needed, they'll get ported to the new API eventually.
See also Francis's message Running unit tests in current CVS to the <development@logreport.org> mailing list about Lire unit tests and Test::Unit. The current CVS contains several unit tests which were added as part of the DLF converter API upgrading. Unit tests make it easier to modify the internals while maintaining confidence that everything still holds together. See also Chapter 15. Making Lire "Test-infected" in the Lire Developers Manual.
The DLF converters are no longer aware of the underlying DLF implementation. (i.e. print to STDOUT or whatever). A output_dlf is used for that purpose (or it could be part of the dlf_maker functionality).
Space and 8bit printable characters are no longer removed.
The DLF API supports log continuation. See the thread About log continuation feature on the <development@logreport.org> mailing list.