<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 10/16/2013 08:18 PM, Jeremy Powers
wrote:<br>
</div>
<blockquote
cite="mid:CAEgUq=fwwjATAK3JyVvTdwjCW0DeQk3nfrzL8L5Ec14SVE+_qA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Short version of below:</div>
<div>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.</div>
<div><br>
</div>
<div><br>
</div>
<div>On Wed, Oct 16, 2013 at 12:30 AM, Robert Schadek <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:realburner@gmx.de" target="_blank">realburner@gmx.de</a>></span>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div class="im">
<div>no hierarchical logs, KISS just create a logger with
different destination. new FileLogger("myDevLog"); $
tail -f myDevLog</div>
</div>
<div class="im"><br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
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 ....<br>
<blockquote
cite="mid:CAEgUq=fwwjATAK3JyVvTdwjCW0DeQk3nfrzL8L5Ec14SVE+_qA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div class="im">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">Configurable log ouput with
custom fields (time, thread, etc).</div>
<div class="gmail_extra"> - required for making log
output match predefined formats</div>
<div class="gmail_extra"> - include needed metadata
in the log line</div>
</div>
</blockquote>
</div>
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. <br>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
</div>
</blockquote>
logMessage(LoggerPayload); is your all powerful hookpoint.<br>
<br>
</body>
</html>