Le 27/4/16 à 14:16, Denis Kudriashov a écrit :
2016-04-27 10:43 GMT+02:00 Norbert Hartl <norb...@hartl.name
<mailto:norb...@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.
not necessary
we could have Log being a potential wrapper.
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
