On 5/14/2011 3:35 PM, Andrei Alexandrescu wrote: > On 05/14/2011 04:56 PM, Michel Fortin wrote: >> On 2011-05-14 17:31:30 -0400, Jonathan M Davis <jmdavisp...@gmx.com> said: >> >>> So, I do think that knowing which thread is logging what could be very >>> important for some programs, but I don't think that separating the log >>> files >>> is necessarily a good idea. If you did, you'd lose timing information >>> (unless >>> the time is at the beginning of every log line (which could also be >>> useful), >>> but then you'd have to read the times and compare them to see what >>> happened >>> before what). So, I'd be all for some options and extra information which >>> could be added to each log line which would help debugging, but I >>> don't think >>> that thread-local logs is a great idea. >> >> I'd even go further and question whether it makes sense to have info, >> warning, and errors be written to separate files. >> >> 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. But I do plan to > offer ways to manually override defaults, e.g.:
Depends on the app. I desire logs for my server to be sent over a socket to a centralized aggregator. But then I've got, um, well, a _lot_ of servers.
