Re-architecting Logger into Actor Framework (Feature Request)

[DanielAllis]

I really love Logger right now, so this suggestion is purely hypothetical. I have been using Logger as part of some Actor Framework based applications. We started with a PPL of the logger code so that we could treat Logger like a standalone library that can be swapped out or shared as needed across multiple application development efforts easily.

I was wondering if anyone else has ever suggested converting the Logger architecture to the Actor Framework so that the FGV would map over to class data and the listeners would be spawned actors instead of just passing a listener queue. This is not a fully baked suggestion, just thinking out loud.

[volks73]

Thank you for the kind words and support.

Actually, I have been considering a re-write (v2.0?) to a class-based structure for this package for a while. An Actor Framework-based implementation is inline with a next generation implementation. I would like to make the API more extensible and customizable. For example, I would like to have a Writer class that can be sub-classed for logging to a file, console (stdout), syslog, TCP server, etc. Each writer could have its own level, format, verbosity, etc. This is more inline with the Log4j, Log4cpp, Log4net, etc. libraries in other languages. Another feature, I would also like a Format class so the log statements can be customized with different formats. Each writer could be an Actor, too.

My current thought was to make a completely new package/project separate from this one that is class-based (actor or otherwise), and even call it something else, but it could easily be Logger v2.0 as well. Time and capacity have prevented me from making any tangible progress along these lines, but it is definitely something I have thought about.