Suggestion: Support a compression step during rotation

[lilyball]

This crate looks like exactly what I want, except for one thing: I want to be able to gzip my logs during rotation.

This should be a configuration on the RollingFileAppender. If set, when the file is rolled over, it would be passed through a compression stage first, which causes all pending writes to block until the compression is finished. The appender would also have to use this flag to determine what filenames to check for when renaming existing logs, as the compressed logs would look something like prefix.1.gz.

At the API level, I need to be able to provide the file extension for rotated logs (probably as a const), and I'd need to be able to do the actual compression (probably as a blocking function that returns io::Result<()>). The compression function should take the source path and a temporary destination path (possibly just base_filename.ext, no log number). When the compression finishes this crate can then rename the destination path to the expected rotation path and delete the source log.

[kevinhoffman]

@lilyball - it's a nice idea. apologies on the delay not much time to spend on this lately. I would envision the order during rotation to be slightly different:

• Rotate the file as it currently happens and continue writes to the new file -- do this as quickly as possible to not block logging (compression could take a while on large logs).
• Trigger some "file just got rotated" callback (provided to the RollingFileAppender) that accepts the full path of the recently rotated file where the caller could do some desired logic, e.g., schedule some async work to compress the contents of the recently rotated file and write it to an alternate prefix (e.g., compress prefix.1 and store to prefix.1.gz then delete prefix.1)

RollingFileAppender would also need to be enhanced to receive an optional additional suffix to check when it's rotating files so that it would properly rotate files that had the uncompressed or the compressed prefix.

This strategy would allow the application to implement any arbitrary compression/post-processing of logs and keep decisions on whether to do it synchronously or asynchronously and what compression algo to use outside the scope of the module. If the caller chose to process compression asynchronously outside of the callback there could be a race condition if the logfile is rotating fast enough, but it seems like that would be an acceptable edge case. What do you think?