I’m glad there were some many responses on the SystemLogger announcement from Stef. There popped up a lot of good ideas that will help to make it even more useful. I just wanted to add some points in a more compact fashion about this logging utility.
One of the core ideas is „logging objects and not strings“. Strings are useless when distributing information about state/objects/values. Strings are a requirement of the output medium we put our log information onto. So what needs to be achieved is just to have a conversion to strings as late as possible. This is before writing it to a stream. Strings are not the only format we want to have our log information converted to. One more reason not to produce strings in the first place. The way it is now you can have easily three loggers: - The SystemLogger which logs the object in memory. This can be used by a UI tool to display whatever information it want from the objects - A typical file logger that converts the object to a string and puts the converted log onto that stream - A database logger that converts e.g. to JSON and puts the converted log onto a socket that is connected to a database It maybe the case that not every log entry is suitable for each logger. That is why you can filters on the loggers to make every logger consume what I can/should consume. The SystemLogger should also stay very simple and should have plenty of extensions. There are a lot of extension points in the SystemLogger already but there is surely the need to improve that. No problem just complain about it. The basic module SystemLogger should only consist of the most basic classes so there are no further dependencies to it. This should make it easy to load it into the image without much thinking because it doesn’t pull a huge pile in the back of it. The extensions add support for the most common things like stream loggers, formatting and so on. Those extensions are most likely used for supporting different logging types and media. The above can be considered as it is now. I just want to raise attention for something more. The topic was already raised (I would have bet on that): Log levels. I don’t think strings are good log objects and I don’t think log levels are something every log information should have. What we are used to is those typical logging types. But these are syslog entries or even unix syslog entries. I really don’t want that the creep into the framework. Don’t get me wrong I want to have that syslog entries are properly supported because a lot of people like to use them. But I don’t want the main object model spoiled by that. Ok, we made it from strings to log entries. But can we just go a little step further and make it log events? It is just something like an announcement that has a specific purpose: being catched by the log dispatcher and distribute in a certain way? Imagine logging a HTTP response object. That has already internal state about being an error or not. So a log event carrying a http response that is converted and put into syslog can answer its severity depending on the state it already has. Why? Because we are logging objects that have decent behavior. The log level is meta data about log information that is unable to carry additional information (like a string). By not logging strings we solved that problem and removed partially the need to have log levels in the way they are. I know that a lot of use cases will still need to log level instVar but I hope I could raise attention to the fact that it shouldn’t be contained in _the_ log object. Norbert
