I'd like to mention my TraceEvent and TraceMonitor classes, again, as it supports most of what you guys are talking about. I believe I have resolved my package naming, so you can find these classes in the SqueakSource's Cryptography repository in the OCapPresents package.

TraceEvent is a single loggable event class with timestamp ivar, generic msg ivar, filterable domain ivar, remote ivar. These ivars are converted to strings during logEvent handling in the monitor, so the msg ivar can hold a user-defined loggable event objects that convert to a preferred string. There would be no need to write separate wrappers for each use.

The monitor can have various domains enabled or disabled: use TraceMonitor>>#enableDomain:/#disableDomain: with a symbol. My use has a bunch of convenience methods for my domain use, but a new domain can be added and one can use the #etrace:msg: variety, which accepts the domain as the first parameter and the domain specific msg object as the second parameter. The monitor can write to multiple trace streams.

I am missing logLevel, though I tried to add severity but it is non-functional. It would be easy enough to add. I do not know if this aligns with the Announcements solution you all are talking about or if it meets all your needs. It is sounding like it meets most of the logging domain information, it is filterable, has multiple output streams, uses the event system so it is lightly couple to the domain.

Whatever solution is arrived at, I hope it is a shared infrastructure service in squeak as well, along with Fuel, then I would likely switch to using the standard.

On 04/27/2016 08:16 AM, Denis Kudriashov wrote:
2016-04-27 10:43 GMT+02:00 Norbert Hartl <norbert@hartl.name>:
I must confess I cannot follow you completely. What we were/are talking about is that the assumption a logging entry needs timestamp, log level and such is not appropriate. If you have legacy syslog style logging in mind it appears natural but for a lot of use cases it is not.

Could you provide example where it is not?
��
Even if you could say that a timestamp is part of the logging domain it is not said if that timestamp needs to be part of the log object or the logger consuming this object. This question arises for every quality of a logging object. Even the logging level could be some behavioral quality that a logger matches to log levels. Contrary to this is logging thisContext which has to be done in the log object.
I think the hard part is the way of distribution of log objects and filtering of them. While the former is being discussed with Beacon the latter is mostly ignored while being really important. Not having default qualities of a log object is good on one hand but on the other hand the filtering is much harder.��
In SystemLogger we didn't go far enough at first. The Log class contained level and such. That was the reason for me to split it into BasicLog consisting of timestamp and a message object and Log which contains the extra qualities.

My problem with such approach is that it forces me to create hierarchy of log events as subclasses of base log component.��
Imaging that my application already provide hierarchy of events but they have no timestamps. How to log them? Should I use some WrapperSignal?��
Now imaging that application uses some library which provides events too. But this events are log entries themselves. What I will see in my logs?��
I will see mix of WrapperSignal's and normal events. It would be not easy to analize such log.

That's why I want unified log entries. I would model it with single class LogEntry which nobody needs to subclass. It would contain logging domain information: timestamp, importance level, user message and whatever. And it would have content property to keep logging object. So our tools can rely on this structure to make it easy to work with logs. And when anybody will look at particular log he will be sure that logging object is inside "content" variables of each record

-- 
Robert
.  ..   ...    ^,^