Re: Re: Working Version of Net_Monitor - Please Review :)

Hi again Robert Peake who wrote:

The resetState() method is samewhat too violent, as it will provoke the resending of all alerts.

resetState() will reset the previous state information. The purpose of this feature is to allow end users to reset the previous state, add new services and alerts, and run a completely different monitoring session if and when the previous monitoring session's state information is no longer relevant.

Excuse me, I did read the code too quick. ;) Anyway, I don't understand where this resetState() could be used, as it's just acting on some internal properties which only exist in mean Monitor object life.

It should be possible to reset only one service for example.

This is something I can look into. I suppose you might want to forget that a single host/service combination in a monitoring session has returned a non-OK result. However, this seems more rare than clearing the session state altogether to me.

So, e.g. in my monitoring I have put a mail server wich stutter. I mean for some technical reason, this server going down and try to reboot all the time. (unfortunately I recently got this actual case) So on my lovely handy, I get SMS after SMS saying "up" and "down". (unfortunately your package was still not ready, so it's a dream) Then as I know some colleague is handling the stuff, I decide to shut off the alarm, could be only for me or for everybody. When colleague solves the problem, he/she likes to rest the alarm.

BTW, it's to be hoping, nobody puts a "\t" in message,

AFAIK, messages returned from Net_* packges don't have tabs in them. I will look at possibly quoting the return message just in case.

AFAYK ! When somebody in year 2047 handle you still widely used package and forget that, the it's loosed. When some traduction of your message is madde by someone ignoring this point, loosed again. That's right you could escape the content so to be protected.

I think this save format is quite dangerous.

What format do you think would be more safe? I do believe that some kind of serialized xml,

(Hi Justin we just crossed over) wddx or session_register() more closer to the PHP variables could be more flexible and safe.

It's not directly concerning your package, but to get it work some user interface would be usefull to handle the services and recipients lists.

See the 'examples' directory for an example of using an INI file to set up a monitoring session. Using this approach INI files could be passed as options on the command line, allowing for easy scheduling of monitoring sessions from inside a scheduler like crontab.

so even have the user (un)subscribe from itself.

This would be a simple matter of a Net_Monitor->setAlerts(). I leave this up to the end user who integrates this into his/her application, since the purpose of Net_Monitor is monitor network services, not provide mailing-list functionality. That's what I mean, you know in my dream story there above

I'm in some restaurant with ..., and I just have my handy there !

One technical remark: why do you need to make copy of $this->stuff in $stuff everywhere ? Most often you can directly work on $this->stuff. The same for subarrays, why make a copy ? you may use so many indexes you like as: $secondary[$j]['service']

Mostly for readability. I do use multidimensional array references where it is obvious what I am doing. Sometimes copying $this->variable is just convenient and sometimes it is necessary because I am changing the copied variable but do not want to change the class variable.

The stateDiff() method could follow both arrays in one loop not need to double loop and reset !

Actually, it is necessary to act destructively on both arrays in the first set of nested loops. This is because the behavior of the alert call is to only return data when there is a problem. So, leftover problem states from the previous set of tests have to be identified to be reported as having changed to OK. This means removing all intersecting states, reindexing the previous state array, and then traversing the array setting the message and code to "OK." If the system were reporting everything, including successes, a recursive version of array_diff_assoc would work here. However, it is less efficient and really less desirable to report all the OK states, since OK states are only reported when they are a *change* from a non-OK state. I never ment that should become recursive.

Nor am I such a guy to run after CPU picoseconds (time is loosed elsewhere) Just your dream package is running periodically, all the time. And, imagine, I have a success story for you: it's so cute so I build a free (or "quite" free) service for all those bloody guyes they just want to know each 15 minutes if one given web doc has changed. They just like to get it everywhere just on handy. My service get 10,000 clients 2 loops can give 100,000,000 run of irrelevant copies in each functions. I hope I can give you soon better as blah-blah, a copy with parallel follow up of the both arrays. (so far I got it right, it should be possible) Don't tell me such a success is out of reach. Best. -- bertrand Gugger (toggg)