Hi,
> On Apr 20, 2016, at 10:53 AM, Norbert Hartl <norb...@hartl.name> wrote: > > Denis, > > >> Am 18.04.2016 um 18:28 schrieb Denis Kudriashov <dionisi...@gmail.com>: >> >> Hello. >> >> Year ago Beacon and SystemLogger were announced. There was big discussion >> about them. And there were plans to provide single solution. What was done >> around that? >> > we had some talks but nothing happened afterwards. The whole discussion went > somehow off track. The good part is that we had a conclusion that we want to > log objects instead of strings. The bad part is that we forget to talk about > the "logging" part of it. And the discussion and actions are not a good > example for collaboration rather the opposite. > > The SystemLogger started as a project to build a small core about what is > usually done in logging frameworks. Usually log messages are strings with a > severity level like error, warn, etc attached. The log messages are > dispatched to a central location. At that location there is a bunch of log > message consumers that filter by severity level or other criteria. This > filtering consumers are attached to sinks that store the messages in some > format somewhere. The sinks implement formatting and adaptation to storage > like files, syslog, database,… > > We want to do better and we care about objects instead of strings. In case of > writing to a file it will be a string anyway. So we can see that "logging > objects" means that the distribution of a log through the system should > happen as objects with rich interfaces. And it means that the conversion to a > string should happen (if needed at all) at the latest possible moment. So in > my opinion the logging framework should support: > > - having an easy way to emit any kind of log object. The most basic thing a > log entity should have is a timestamp. Around it there could be some common > use cases but most of it is application specific. > - multiple log consumers > - filtering of log entities. IMO this includes filtering of objects you log > to store. In a typical scenario where you would have a severity level you > only want to log certain messages. This can also include filtering for > special types of objects. That would mean you filter the kind of objects the > consumer can understand > - storage facilities. It is quite important to support files storage in many > flavors, logging to syslog, logging to database etc. Without that you are > just logging in memory and I'm not sure if a lot of people would agree that > this is what is meant by using the word logging Good summary. When we discussed about adopting Beacon we also agreed that we will use the code or at least the experience of binding to concrete storage facilities that exist in SystemLogger. > As an example I can put one of my projects where I use SystemLogger. When > sending a push notification I log/emit an object/event of type COMessageSent > with sublcasses for apple, google, etc. It is emitted to a central location. > In SystemLogger there a three loggers configured. One is in memory and counts > the number of events per class. One takes the object, converts it into a > short string representation like "apple push sent to XXXX" and sends it via > syslog/UDP to a central logging server. Finally the third one takes the > object, converts it to json and stores the json in a elasticsearch database. > The database allows me to do all sorts of statistical analysis of the data > over a long time frame such as number of push messages per month for one > year. Which looks like this > > <Bildschirmfoto 2016-04-20 um 10.24.36.png> > > So if you take my point of view then Beacon is pretty useless. SystemLogger > and Beacon both use a singleton to dispatch log entities. This is incorrect. Beacon does not require the singleton. We just have one for convenience, but you can use any announcer for the purpose. That is the beauty of it … the fact that we do not have to reinvent anything because it is already provided by Announcements :). This was also a point that was made by Sven and is what I took into account when I designed Beacon. Please read the sections "Beyond global bindings”, and “Logging any announcements from any announcer” from: http://www.humane-assessment.com/blog/beacon The singleton convenience is for replacing the places where Transcript is being currently used. > In SystemLogger has own implementation of registry for that loggers. Beacon > uses Announcements for it. That's basically the difference. I like the idea > of using Announcements and not invent yet another distribution mechanism. But > with Announcements you can only filter by class and not by instance. > So it cannot do what system logger can do. Doru writes that he is working on > that and it would be great. Although I have doubt this can be done performant > I would be lucky to have it. Indeed, I think this is important. However, I also found that going extreme in creating signal types is quite powerful and enough for practical purposes. The cool thing about having fine-grained signal types is that you can also define easily dedicated inspector presentations. > On the other hand Beacon implements a handful of classes for some use cases > but nothing more. So I see Svens point that you don't need it really because > Announcements are there anyway and most of the stuff is application specific > so I can just do that without having to integrate a "framework”. Exactly :). These are convenience, and the cool thing is that people can just choose various levels without having to necessarily buy into the complete framework. We do not get often chances like this :) >> What exactly should be merged between this libraries? Was Beacon or >> SystemLogger planned to be end solution? >> > I'm not sure anymore. I can see some good things in Beacon that enable to > register a logger for part of the execution. The drawback is that if you > think about output facilities like log files there is no central place to > attach it. And I surely don't want to have log configurations in the middle > of my code. Beacon is not well thought in that direction, yet. I do not understand this part and I might be missing something. Could you go into details about where you see the log configurations problem in Beacon? > IMHO I'd like to have a SystemLogger with the distribution of objects like it > is done in Beacon. Filtering is to be solved. This is hard to do with > Announcements and to be honest I don't really like it how it is done in > SystemLogger. I think that if we invest in the filtering part we can consolidate around Announcements. >> We definitely need legacy logging tool for Pharo. And I am going to work on >> this direction. >> Personally I prefer metaphor and names from Beacon. But both libraries >> implement similar idea. >> > Agreed. As I said above. If you take to point of view from legacy logging > tool Beacon is not a big help. I do not understand what you mean by legacy logging. Could you explain? > But the ideas in it are good and should be integrated somewhere. If you are > talking about legacy tooling it might ok to use the terms logging as well, > no? I personally like the work Beacon but in my opinion it is wrong for this > purpose. A beacon sends a uniform signal in order to be discovered. The > Beacon code sends signals to a beacon. And I can register at the beacon in > which signals I'm interested in. Feels wrong to me. Beacon is a central place which is both discoverable and propagates messages around to whomever is interested in consuming them. From this point of view, I think it works. Cheers, Doru > Norbert > -- www.tudorgirba.com www.feenk.com "Some battles are better lost than fought."
