On Thu, May 17, 2012 at 3:43 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

So what are the candidates? Does anybody has experience with toothpick since it is MIT and even have a documentation (I will probably write  chapter on it to understand it).

what do you mean by structured? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

On 17 May 2012, at 15:43, Stéphane Ducasse wrote:

So what are the candidates? Does anybody has experience with toothpick since it is MIT and even have a documentation (I will probably write chapter on it to understand it).

It will be hard to get everybody on the same line, I'm afraid. One more data point (every body has its own logging framework) Zinc-HTTP-Logging It is based on Announcements. Is is in 1.3, 1.4 and 2.0 by default. This is a subsection from the upcoming documentation (in Markdown format): ## Logging Log output consists of an arbitrary message preceded by a number of fixed fields. Here is an example of a server log. 2012-05-10 13:09:10 879179 I Starting ZnManagingMultiThreadedServer HTTP port 1701 2012-05-10 13:09:10 580596 D Initializing server socket 2012-05-10 13:09:20 398924 D Executing request/response loop 2012-05-10 13:09:20 398924 I Read a ZnRequest(GET /) 2012-05-10 13:09:20 398924 T GET / 200 1195B 0ms 2012-05-10 13:09:20 398924 I Wrote a ZnResponse(200 OK text/html;charset=utf-8 1195B) The first two fields are the date and time in a fixed sized format. The next number is a fixed sized hash of the process ID. Note how 3 different processes are involved: the one starting the server (probably the UI process), the actual server listening process, and the client worker process spawned to handle the request. Finally, the single capital letter indicates the category. Then the actual message is printed. Both ZnClient and ZnServer implement logging using a similar mechanism based on the announcements framework. ZnLogEvents are subclasses of Announcement sent by an HTTP server or client containing logging information. A log event has a TimeStamp, a Process ID, a category and a message. The following categories are used: #info (I), #debug (D) and #transaction (T). To help in the implementation, a ZnLogSupport object is used. A hierarchy of listeners under ZnLogListener can then be used to process log events. Log listeners feature a filtering mechanism. The following concrete listeners are provided. - ZnTranscriptLogger - ZnFileLogger - ZnStandardOutputLogger - ZnMemoryLogger To log something, send #info: #debug: or #transaction: to the log support object of a client or server (accessible by #log). The argument can be either a string or a block that will only be executed when logging is actually enabled. server log info: [ 'User ', self getUsername, ' logged in.' ]. The Zn logging mechanism using an internal lock to make it thread safe, but it does serialize logging by multiple processes. It is important to make the time spent inside the log block short and non blocking. You can customize a listener before adding it to a log support. The following example asks the default server to log just transaction events to a file named 'zn.log', next to your image. | logger | logger := ZnFileLogger onFileNamed: (FileDirectory default / 'zn.log') pathName. logger filter: #transaction. ZnServer default log addListener: logger. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill