Status: Conceptual
Responsible: Joost van Baal e.a.
Prerequisites: Section , “Configuration API”, Section , “Storage API”
The online responder we offer on our website should be able to support all the features the command line Lire supports. Installation of a responder should be better documented and easier. There was an initial proposal sent to the <development@logreport.org> mailing list in the message PROPOSAL: New Online Responder Architecture.
Status: Conceptual
Responsible: None
Prerequisites: None
The current DLF schema of the email superservice is starting to show its limits. A lot of information is lost in the email log files and several important reports (like refused connections, spam control, etc.) cannot be generated. The schema should be rewritten to closer resemble the log that one actually sees with different fields for anti-spam activity, message collection, routing, etc. This will make writing email DLF converter a lot easier. The current DLF schema could become a derived schema and the stateful logic that is replicated across all email service could be moved to a generic analyser.
Status: Not started
Responsible: None
Prerequisites: None
Standard internationalisation components like xml-i18n-tools or gettext should be integrated into the framework. The XML components should also be modified to support other charsets than basic ASCII.
Lire should get i18n-ed, and support other languages in its error messages and other output, as well as in the report specifications. People have requested l10n to French. This is a long-term task.
Status: Not started
Responsible: None
Prerequisites: None
To make the Lire framework usable in more contexts, 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.
There should be a better configuration interface than the lr_config script we offer now. The CGI interface should get completed. A GUI interface should get added.
Some research on GUI libraries has been done by Plamen Bozukov in September 2001 (Message-ID: <Pine.LNX.4.10.10109271704180.25208-200000@pozvanete.bg>). He came to the following conclusion:
Table 1. Comparison of GUI libraries
score 1-5 | GPL | portability | requirements | easy | features | binding |
---|---|---|---|---|---|---|
Qt | 4 | 5 | 5 | 5 | 5 | 3 |
V | 5 | 5 | 5 | 4 | 4 | 2 |
FLTK | 5 | 5 | 5 | 4 | 3 | 5 |
GTK | 5 | 4 | 5 | 5 | 4 | 4 |
WxWindows | 5 | 5 | 4 | 5 | 5 | 5 |
Tk | 5 | 5 | 5 | 3 | 4 | 5 |
License: QPL/GPL. For windows version, license is possibly problematic. Portability: Microsoft Windows 95/98/2000, Microsoft Windows NT, MacOS X, Linux, Solaris, HP-UX, Tru64 (Digital UNIX), Irix, FreeBSD, BSD/OS, SCO and AIX. Requirements: C++ Compiler X libraries for Unix. Binding: Perl-binding is very old - Last updated November 17th, 1997. Python and Ruby.
License: GNU LGPL. Portability: Windows,OS/2,Unix.
License: LGPL. Portability: Unix,Windows,OS/2. Requirements: C++ Compiler X libraries for Unix. Bindings: Perl: 2 different solutions; Python
License: GNU LGPL. Portability: Unix, Windows. Requirements: C Compiler X libraries for Unix. Bindings: all possible languages. There is the glade interface builder which makes it easy to design GTK interface.
License: GNU Library General Public. Portability: Unix,Windows,Mac. Requirements: C++ Compiler GTK libraries for Unix. Bindings: Perl, good binding for Python.
Portability: Windows, Unix, Mac. Bindings: all possible scripting languages.
More information on various GUI toolkits is on The GUI Toolkit, Framework Page.