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

[Stefan Schmiedl]

On Thu, 09 Jul 2009 09:27:59 +0200
Joachim Jaeckel <address@hidden> wrote:

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

maybe I blubbered incoherently, so please excuse me for not being clear.

> > 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?
> 
> I don't think so. Logging should be less user-interactive as possible
> in my opinion. (And configurable to fullfill the needs of the
> programmer.)

As user of the logging facility (i.e. application programmer), I'd like
to be able to write logging information 
 - to a file, eg something like Logger onFile: aPath, where I want to
   decide on whether the file is being replaced (session log) or appended
   (audit log)
 - to a string, so that I can easily display it in my application, eg
   when showing the results of a batch process
 - synchronously or asynchronously
Since I know what should happen to the log, you either need to provide
for all my potential needs, a battle which you're bound to lose, or you
simply refuse to take the responsibility for something that lies beyond
your domain and leave it with me.

Hence my idea of what a logging facility should support: streams.

When I open the log file, *I* decide whether to overwrite or append,
the logger uses the properly configured stream. When I want the log
as a string, *I* give you a "String new writeStream". When I really
need buffered logging, it should be *my* job to provide a flush method
which defers to a buffer manager for actually writing the data out.

So, ideally, your logger will require a duck quacking "nextPutAll:" 
and "flush" and that's it. You will have a slim core functionality,
which I can plug into whatever I want.

s.