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

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