On 10/16/2013 08:18 PM, Jeremy Powers wrote:
> 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 <realbur...@gmx.de
> <mailto:realbur...@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.
I still don't feel that hierarchy building should be part of std.logger,
as it is way to heavyweight. But thinking about MultiLogger made me
realize, that I need a way to identifier Logger to remove them. So
currently, I think MultiLogger will have an AA and Logger will have
names (string). You do the math ....
>
>
>> 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.
>
logMessage(LoggerPayload); is your all powerful hookpoint.
