Suggestion: Support a compression step during rotation about rolling-file-rs HOT 1 OPEN

@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?

from rolling-file-rs.