Implementing std.log

[Andrei Alexandrescu]

On 5/14/11 7:13 PM, Brad Roberts wrote:
> 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<jmdavisProg at 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 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. 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.

We'll need to provide socket streaming support.

Andrei