On 2011-05-14 18:35:32 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> said:
On 05/14/2011 04:56 PM, Michel Fortin wrote:
I'll also question whether they should be written to files at all by
default (as opposed to stdin and stderr). I'm aware initLogging's
documentation says: "If logging is effected without having called
this function, all parameters are at their default values and all
logging is done only to stderr." So basically, I'll get what I want if
I never call initLogging, but then I can't control verbosity and other
settings using --v and other flags passed as arguments.
A server app must log to files, no question about that. We'll need to
add rotation etc. in the future.
No question about that.
What I'm questioning is whether the typical use case for logging will
be a server app. Ideally, I think we should encourage people to add
logs everywhere it makes sense, if only as a debugging aid. If the
default behaviour is to write logs to files it starts to look like a
specialized tools for servers and such and it appears less relevant for
other use cases.
But I do plan to offer ways to manually override defaults, e.g.:
void main(string[] args)
{
logtostderr = true; // override default
initLogging(args);
...
}
The default value for "logtostderr" should be reversed. Let's not make
a server application the default use case for std.log, shall we? Even
if that was the idea, the default is currently to save files in /tmp
(or equivalent), which does not seem very appropriate for a server to
me.
I think logging to files should be enabled only explicitly by providing
the default logging directory as an argument:
initLogging(args, "/logdir");
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/