On 01 Mar 2020 at 10:50a, g00r00 pondered and said...
Perhaps consider more granular options for resetting data? I'm not su how that may work / be feasible, perhaps something like
reset_daily
reset_weekly
reset_monthly
You can sort of already do this if you set it to reset 7 for weekly for example. But I am open to any ideas of course if you can think of a better way to do this.
But if you reset every 7 days how would you ever get the 30 days stats?
That's kinda where my brain is going, just not sure how to achieve both at
the expense of one?
Yep also good, it should clear echomail and filebox.
It should clear all echomail and filebox. I've already finished the implementation of all the features I showed in the original message but none of it is actuall tested.
Yep that sounds good. And some kind of report is generated somewhere for
admin and/or for possible posting to echomail?
I also fixed the MIS POLL display error too.
Coolio... it seems the display window is limited in that you can only see how many concurrent active connections the window will display, so if it were 12 I'm not sure how it would display? Regardless it seems a nice to see thing,
but the functionality of increased concurrency is the main thing in my mind that appeals the most to me.. it's great.
This looks fine bar the fact I am unsure how many failures should cou perhaps this should be a figure expressed in days or hours?
That makes sense. Maybe a combination of two factors?
I could base it entirely off of the last successful connection time but then the issue with that is if you screw up your batch file and Mystic never actually TRIES to send anything (because you called "miss poll" instead of "mis poll") then you could end up with all your crash nodes being demoted to hold (when their setup was fine and yours was actually broken).
Yep that would be bad.
Because of that maybe it should be based off of a dual factor:
; Node must have a combination of both of th following values before having ; mail type and filebox type set to hold:
; Number of bad outbound connection attempts
crash_errors = 7
; Number of days since last successful outbound connection
crash_days = 7
I like this. what about if you have a node that is only ever set up for HOLD so you never poll it but you need to know if it's been inactive polling in?
I know we have an inactivity setting being kicked around, but how are you defining inactivity?
; Set the number of days of inactivity before an Echomail Node is
; automatically deactivated (or 0 to disable)
inactivity = 0
e.g.
Inactive: 0 days Last In: Never
Received: 27 (29KB) Last Out: 01 Mar 2020 17:06
Sent: 3,607 (7,037KB) Reset: Never
Is inactive only looking at Last Out, and that is recorded as the date a node had traffic crashed to it or the node picked up packets on hold for it at the HUB?
Another question,
; When set to TRUE, MUTIL will remove any files or mail packets from the
; node's outbound queue upon deactivation from inactivity
clear_outbound = true
Will Mystic know the difference between an echomail node set as inactive by
the sysop and one the system has determined by the rules being set in this stanza is something to be removed?
You wouldn't want a deliberately set inactive node by the sysop to be wiped.
I guess you could add a switch in the echomail node settings much like in the User editor when you set a user to be deleted... so you can set Clear Outbound manually to Yes and have MUTIL deal to the echomail node packets/files...
Or even one to protect against an automated purge... perhaps that's overkill but I am thinking along the lines of the User Editor options and trying to apply such notions to echomail nodes :)
--- Mystic BBS v1.12 A46 2020/02/29 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)