Re: [mh] Your help re Genericising Error and log handling

Giles,

Thanks again for your work on this.

Yes, for sure, the user code print_log function (is that what you are 
calling print_log_private?) should get called for all logs, severity set 
or not, so that it can process both new and legacy modules.  To me, 
that's a very useful hook as, at least initially, almost nothing will 
have a priority set.

Regarding suppressing logs, what about adding a new severity level 
"NONE" such that, if user code set the severity on any log to NONE, then 
the print_log_simple call is skipped entirely.

I agree about syslog, it should be possible, in the user function, to do 
anything -- including sending a MH print_log to syslog also.

Jeff

On 2021-01-13 8:56 a.m., Giles Godart-Brown wrote:
>
> Thanks for the input Richard.
>
> Print_log_simple (the old print_log) calls logit, so I think I've 
> preserved backwards compatibility (its been running all day so far).
>
> As  for integrating with other tools, once we have allowed a developer 
> to grab the print_log messages before they are sent to disk, the world 
> is their oyster, do you have some Linux  hooks we could put into an 
> example?
>
> It may be that we should remove the restriction that print_log_private 
> is only called if it exists AND a severity is set, that way you could 
> re-route all legacy messages into anything you want and do regex's in 
> your print_log_private to decide what to do with the message.
>
> Part of the motive for this is that on some restricted platforms (e.g. 
> those based on SD cards)  you may want to selectively reduce,  use 
> email instead of logging, or even eliminate logging completely when 
> you aren't debugging or something dreadful has happened. This 
> technique enables this without having to look at the logs after they 
> have been created or delve into every instance of print_log.
>
> Another motivation is that bi-directional devices like Tasmota, give 
> immediate feedback when they go off-line or an attempted state change 
> fails, it is good to pass this onto say a phone messaging app like 
> growl in real time.  If we encouraged core developers to use the new 
> print_log with severity and source, we can let implementations 
> intelligently decide how to deal with these messages  without messing 
> with the core code.
>
> G
>
> On 13/01/2021 13:26, Richard F wrote:
>>
>> My $0.02, only just caught this as I'm on the digest feed....
>>
>> Since the basis for the "severity" etc seems to be the Linux logging 
>> system, there should be a hook into that so that the output can be 
>> (re)directed there, as an alternative or addition to for certain 
>> severities of event, and we should ensure the severity/level 
>> characteristics are synchronised.  Maybe that exists somewhere, but I 
>> don't recall seeing it.  There's also the existing MH "logit" 
>> function, that needs to be considered.
>>
>> There are plenty of tools to manage Linux logfiles, some could be 
>> helpful. The venerable Logwatch is one such that could provide daily 
>> summary / alerts with a suitable config file.
>>
>> Richard
>>
>> On 13/01/2021 9:49 am, Giles Godart-Brown wrote:
>>>
>>> Summarising the comments ; the desire is for print_log to be called 
>>> unchanged for legacy apps, but to allow developers to intercept 
>>> print_log requests and route them accordingly (email, SMS, growl, 
>>> print, tasker, IFTTT...)  and to do this with the minimum impact
>>>
>>> Here is what I have built and tested today. If its OK with the 
>>> forum, I'll create a pull request.
>>>
>>> <changes to mh>
>>>
>>> # 13-jan-2021 new print_log added and old print_log renamed 
>>> print_log_simple to allow
>>> # 1) optional additional parameters severity and source
>>> #    severity should be one of EMERGENCY, ALERT, CRITICAL,
>>> #    ERROR, WARNING, NOTICE, INFORMATIONAL, or DEBUG
>>> #    message is reformatted as [source] severity message
>>> # 2) substitution of print_log_private() if it exists and severity 
>>> is defined
>>> #    otherwise functions as the old print_log
>>> sub print_log {
>>>     my ($message,$severity,$source) = @_;
>>>
>>>     if (defined($severity)) {
>>>         if (defined(&print_log_private)) {
>>>             print_log_private($message,$severity,$source);
>>>             return;
>>>         }
>>>         $message = $severity . " " . $message;
>>>     }
>>>     if (defined($source)) {
>>>         $message = "[" . $source . "] ".  $message;
>>>     }
>>>     print_log_simple($message);
>>> }
>>>
>>>
>>> # renamed from print_log
>>> sub print_log_simple {
>>>
>>> </changes to mh>
>>>
>>> *And here are the test cases;*
>>>
>>> *test 1 without  a print_log_private()*
>>>
>>> print_log("message");    produces  13/01/2021 09:23:48 message
>>>
>>> print_log("message","WARNING"); produces  13/01/2021 09:23:48 
>>> WARNING message
>>>
>>> print_log("message","ERROR","source"); produces 13/01/2021 09:23:48 
>>> [source] ERROR message
>>>
>>> t*est 2 with a print_log_private() *that prepends 
>>> 'print_log_private' to the source and calls print_log_simple() (see 
>>> attached)
>>>
>>> print_log("message"); produces the following because severity wasn't 
>>> set and so print_log_private not called 13/01/2021 09:27:23 message
>>>
>>> print_log("message","WARNING"); produces 13/01/2021 09:27:23 
>>> [print_log_private] WARNING message
>>>
>>> print_log("message","ERROR","source"); produces 13/01/2021 09:27:23 
>>> [print_log_private-source] ERROR message
>>>
>>> Giles
>>>
>>> On 12/01/2021 20:10, Brian M wrote:
>>>>
>>>>
>>>> On 1/12/21 11:00 AM, Rick Steeves wrote:
>>>>> Might it not make more sense to modify print_log, so that, as is, 
>>>>> it keeps working as expected, but in any case that print_log was 
>>>>> called with more than one parameter then new things happened?
>>>>>
>>>>> That makes all the existing code keep working, but new code (or 
>>>>> people modifying existing code) could just add parameters.
>>>>>
>>>>> If you were going to do a search/replace for print_log, you're 
>>>>> still going to have to find all the cases of it and manually 
>>>>> adjust them for what you want to have happen.
>>>>>
>>>>> That would avoid creating a new function, have it keep working 
>>>>> as-is in all the existing code, and let it be adjusted on a 
>>>>> case-by-case basis. 
>>>>
>>>>
>>>> I agree with Rick.
>>>>
>>>>
>>>>
>>>>
>>>> ________________________________________________________
>>>> To unsubscribe from this list, go to: 
>>>> https://lists.sourceforge.net/lists/listinfo/misterhouse-users
>>>>
>>
>>
>> ________________________________________________________
>> To unsubscribe from this list, go to:https://lists.sourceforge.net/lists/listinfo/misterhouse-users
>>
>
>
> ________________________________________________________
> To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users
>


________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users