Early review of std.logger

[Robert Schadek]

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 <realburner at gmx.de
> <mailto:realburner at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131016/9f2e35bc/attachment-0001.html>