Re: [Help-smalltalk] Logging facility for GNU-smalltalk

[Paolo Bonzini]

> maybe I got you wrong (if that's the case, please excuse),

No problem, discussing and misunderstanding is the best way to come up
with new ideas.

>> Logging should always go to a stream and not be hardwired to
>> assume files.
>
> Does that mean, that the user who uses the logging-functionality should care
> about handling the stream?

First of all, let's clarify that we never talk about the user of the
application, just the user of the logging component (so "user" and
"programmer" are the same person).

In this I agree with Stefan.  It's okay to have a method to quickly
create a logger that writes to a file.  However, this should be just
one of three ways:

1) writing to a file

2) writing to an arbitrary stream

3) a logger created with "Logger new" finally should write either to
"String new writeStream", or to a singleton stream stored somewhere
(in a class variable?).

1 and 3 should be delegating to 2.

> Logging to a stream should be an option in my opinion but not the usual
> case...

That does not mean that the "usual cases" shouldn't be implemented in
terms of it.  Logging to a stream is the basic low-level option, and
every other constructor for loggers should simply create the
appropriate kind of stream.

>> Also, one could implement a "tee" like functionality, i.e.
>> duplicating the log output on both stdout and a file. Or even
>> piping it (eg via nc) to a remote location.
>
> That's something, what I would like to see in the logging interface.

No, that's something that can be useful outside logging, so it must be
implemented as new kinds of stream.

Streams are an exceptionally powerful construct.  All of zlib, iconv,
sockets are based on the abstraction of streams.  For example the
"pipe via nc" case can be realized very easily by just passing a
connected socket to the logger... as a stream!

Answering your other email, I admit I haven't read the code but it's
good that you have output separate from logging.  Now try making the
file output handler just use a StreamOutputHandler.  The changes will
be extremely small, trust us, and will include the socket case for
free.

I would even say that 99% of the output handler's task is to format
the output (so you can have HTML, text, etc. handlers).  The syslog
handler would be pretty much the only handler I can imagine that
cannot work on an arbitrary stream.

Paolo