Big unscheduled items

Featureful Online Responder

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 mailing list in the message PROPOSAL: New Online Responder Architecture.

Overhaul of the Email Superservice

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.

Internationalisation Framework

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.

Support reports in multiple languages.

Status: Not started

Responsible: None

Prerequisites: Section , “Internationalisation Framework”

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.

C Based Implementation of the APIs

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.

Configuration GUI

Status: Not started

Responsible: None

Prerequisites: Section , “Configuration API”

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-5GPLportabilityrequirementseasyfeaturesbinding
Qt455553
V555442
FLTK555435
GTK545544
WxWindows554555
Tk555345

QT

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.

V

License: GNU LGPL. Portability: Windows,OS/2,Unix.

FLTK

License: LGPL. Portability: Unix,Windows,OS/2. Requirements: C++ Compiler X libraries for Unix. Bindings: Perl: 2 different solutions; Python

GTK

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.

WxWindows

License: GNU Library General Public. Portability: Unix,Windows,Mac. Requirements: C++ Compiler GTK libraries for Unix. Bindings: Perl, good binding for Python.

Tk

Portability: Windows, Unix, Mac. Bindings: all possible scripting languages.

More information on various GUI toolkits is on The GUI Toolkit, Framework Page.