What the state of unifying Beacon with SystemLogger?

> On Apr 20, 2016, at 6:05 PM, Denis Kudriashov <[hidden email]> wrote:
>
> Hi.
>
> Thank's for answers.
>
> 2016-04-20 10:53 GMT+02:00 Norbert Hartl <[hidden email]>:
> 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.
> 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)
> • 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 would call it like ObjectLog or NativeLog (following my first sentence about Log).
> Also it is intercepted with SysLog name and I guess that's why it was called SysLogSender and not SysLogLogger.
> • name LogDispatcher.
> 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).
> 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.
>

> On Apr 20, 2016, at 9:05 PM, Ben Coman <[hidden email]> 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 <[hidden email]> wrote:
>> Hi.
>>
>> Thank's for answers.
>>
>> 2016-04-20 10:53 GMT+02:00 Norbert Hartl <[hidden email]>:
>>>
>>> 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.