Short version of below:

I want a powerful logging system.  Maybe std.logging should provide the interface with some basic functionality, allow other solutions to fill in gaps.  Should be able to always code against std.logging, complications added as needed w/o code calling log() caring or changing.

On Wed, Oct 16, 2013 at 12:30 AM, Robert Schadek <realburner@gmx.de> wrote:

no hierarchical logs, KISS just create a logger with different destination. new FileLogger("myDevLog"); $ tail -f myDevLog

Without this provided out of the box, I'd have to create my own framework for such on top for any serious use.  This is arguably the most important feature of a logging framework for a large product.  Once you get multiple people/teams/companies/monkeys contributing to a system, you _need_ a way to distinguish and filter logging from each part.  Spitting to different log files is not a solution in most cases, the 'create my own' would have each module logger spitting to the same place as the root, with the root logger controlling what actually made it to the log.

Simple logging framework should be simple.  But it should also be powerful, without requiring custom boilerplate for more complex usage...  Earlier was mention of getting a module's log via import, this seems a good solution interface wise - basic implementation would just return basic logger, but would allow for a hierarchical solution to be plumbed in without the logging code knowing/caring.

Configurable log ouput with custom fields (time, thread, etc).

  - required for making log output match predefined formats

  - include needed metadata in the log line

I think this has been discussed twice already, no configuration can anticipate all possible needs and will fail fast and hard. So why try, I rather write 7 lines, than wait for a patch to the configuration parser to appear in my production env.

There are two parts to this: making sure the log output conforms to some format, and making sure required information is included.  You can never anticipate what everyone needs for either, but you can provide the tools to enable them.  Conceptually, this means separating the information being logged from the actual output - the basic logging framework doesn't need to even try to cover every case, so long as it provides hook points.