Implementing std.log
    Michel Fortin 
    michel.fortin at michelf.com
       
    Sat May 14 16:43:26 PDT 2011
    
    
  
On 2011-05-14 18:35:32 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail at 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.fortin at michelf.com
http://michelf.com/
    
    
More information about the Digitalmars-d
mailing list