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