> On Apr 20, 2016, at 9:05 PM, Ben Coman <[email protected]> wrote: > > Sorry for not having a better reviewed understanding of both > frameworks, but I have some thoughts from perspective of one user... > > On Thu, Apr 21, 2016 at 12:05 AM, Denis Kudriashov <[email protected]> > wrote: >> Hi. >> >> Thank's for answers. >> >> 2016-04-20 10:53 GMT+02:00 Norbert Hartl <[email protected]>: >>> >>> Agreed. As I said above. If you take to point of view from legacy logging >>> tool Beacon is not a big help. 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. >> >> >> Your words are reasonable. Interesting what Tudor think about it? >> >> There are few things which I not like in SystemLogger (which not means that >> everything is good with Beacon): >> >> name Log to represent records of the underlying "physical log". >> >> IMHO Log means exactly end logging backend like text file, syslog or >> external database. Log is the place where we can explore (read) what was >> happen. > > You are considering Log as a noun, but it can also be used as a verb. > defn "13. to enter in a log; keep a record of; e.g. to log a day's events." > [1] > > Stef said: "Remember that you want to have them short especially for > the main one. This is why in SystemLogger > we have Log instead of what it is LogObject" > from which I understood that Log was the client interface, to be used > like Transcript. I think this is a good idea. It would create the > LogEntry > > [1] http://www.dictionary.com/browse/log > >> And now these backends are represented by subclasses of Logger: >> StdoutStreamLogger, SysLogSender. I would call them StdoutLog, SysLog. >> But with such change we need to call log entry differently. It can be >> LogRecord or LogEntry. I not understand what was the problem with such >> names? (there was some explanation why Log was chosen for this) > > Considering a "log" being the final resting point of the logged > objects, that is the external disk text file or database, then within > Pharo we don't have logs, only processes that write to the external > logs, so Logger seems appropriate. This is except for an in memory > log, which for backend might need both MemoryLogger and > MemoryObjectLog. > > Log would create and send theLogEntry to SystemLogger > which forwards theLogEntry to other registered XXXLogger backend. > >> name SystemLogger for collection based log. >> >> SystemLogger makes me think that it is singleton which is used by system and >> I should not use it for my own application. > > I guess your application would make use SystemLogger via Log at the > front end, and registering backends with SystemLogger. > >> I would call it like ObjectLog or NativeLog (following my first sentence >> about Log). > > NativeLog doesn't seems right. ObjectLog might be suitable for an > in-memory backend, like above I mention MemoryObjectLog. > >> Also it is intercepted with SysLog name and I guess that's why it was called >> SysLogSender and not SysLogLogger. >> >> name LogDispatcher. > > LogDispatcher is okay, but I'm not sure of convention to be associate > the "doer" with the "target" rather than the "item", where > doer=Dispatcher; item=LogEntry; target=final-backend-log; A little > it sounds like its dispatching a whole log rather than one log entry. > Maybe should be LogEntryDispatcher(??) or... SystemLogger as the > marshalling point to forward to other XXXLoggers. > >> >> Here same problem as Log. What means physical logs dispatching? I know it is >> introduced around Log as log entry. But it is not intuitive for me (same as >> Log). > > I don't think Log should be a log entry. It should be the user > interface that creates and sends LogEntries via some XXXLogger. > >> In context of Log as real log (FileLog, SysLog) I would call this dispatcher >> as Logger with same responsibility to register new events in all registered >> logs. >> >> >> announcements LogAdded and LogRemoved in the core. >> >> Why any Logger should announce every log entry? >> I think we not need special LoggerUI app. We can just inspect SystemLogger >> instance to look at all recorded objects. And in perspective of my >> suggestions it will mean that we just explore particular ObjectLog. And we >> can extend GTInspector for this. > > GTInspector would need good live updating, filtering, clearing, > scrolling to keep cursor position as new entries arrive.
It does already. Please take a look at Beacon :). Cheers, Doru > cheers -ben -- www.tudorgirba.com www.feenk.com "Obvious things are difficult to teach."
