If you can help on these subjects or if you have other ideas and suggestions,
you're welcome.

1- Windows port

Some managelogs features are still Posix-specific (like setuid/setgid), generally because
the corresponding feature is not available in the APR library.

The code should be more
portable, especially on Windows. Either the
Unix-specific features have a Windows alternative, or they must be
disabled on Windows.

Then, provide a binary distribution for Windows.

2- CLF option

An option which causes timestamps to be read from the input log lines
(supposed to be in Common Log Format). Allows to run some old logfiles through
managelogs using time-related features.

the logmanager library is already prepared for such a feature as functions
receive the time from the calling program. Today, managelogs always sends a null
value, meaning that the library gets the time from the system clock. So, we just
need the code to extract the time from each log line.

Format can even be auto-recognized (recognition code to be inspired from the
same feature in analog or summary).

3- Info option

An option to display in readable form some information about
a log manager current state (mostly extracted from the status file).

Several
output formats should be available, as detailed, XML, or compact (to be
read by an external script).

Problem : both processes cannot be synchronized
(could run on different hosts).

4- Additional
external hooks

An optional command to be launched when the program aborts on a fatal
error. This command would receive the information on the error, and could
connect with a monitoring system, send a trap... (TBD: Pros and cons of
running this command in foreground or background).

Another external command to be executed when managelogs gets a 'file system
full' error (as it now survives it). This command should be sent only once per
distinctive event.

Actually, both can be gathered into an external 'alert' command, triggered
only when an unexpected event occurs. This command would receive a reason, a
(numeric and string) level, an action code (abort or ignore), a message... and
could make the link with an external alert system.

Note: If the program exits just after having launched its alert command, the
child process must not be killed. So, it may be interesting to run the child
process in foreground (waitpid) when the action code is 'abort'.

5- Time-related features

Unlike rotatelogs and cronolog, managelogs does not support strftime patterns in filename
specs.

I'd like to integrate cronolog's time-related features, but combining
this with the existing features is not trivial (creating directories is one thing, but
deciding when to remove them is another !).

I also have several issues to investigate on the way to manipulate the current
time and how to compute accurate delays from the current local time, especially
with DST.

6- Use a better mechanism for signals

managelogs currently uses a basic memory-based mechanism to manage signals
and avoid reentrance in log managers.

This mechanism should be improved to use system mutexes. And the
logmanager library should become fully reentrant and thread-safe. If it can be
done in a portable (M$-compatible) way, it is still better.

7- Integrate as an Apache module

I don't know yet how to do it, but it can be interesting for heavily loaded or ISP-like environments (with a lot
of virtual hosts).