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 log­ging is ef­fected with­out hav­ing called
this func­tion, all pa­ra­me­ters are at their de­fault val­ues and all
log­ging 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/

Reply via email to