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

From: Date: Mon, 06 Dec 2004 19:25:34 +0000
Subject: Re: Re: Working Version of Net_Monitor - Please Review :)
References: 1 2 3 4 5  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-34851@lists.php.net to get a copy of this message
On Mon, 06 Dec 2004 10:40:39 -0800, Robert Peake <robert@peakepro.com> wrote: > Hi Bertrand, > > > > bertrand Gugger wrote: > > > Hi Robert Peake who wrote: > > > >> Thanks for the constructive feedback so far. I am reluctant to move > >> this to "proposal" yet as my understanding is that I can not edit the > >> main document after it reaches this stage. > >> > > You're wrong, in "proposal" state you can still edit it, even change the > > package's name > > if you want. > > Hmmm, in the mean time you are proposing... > > Yes -- I realized this. :) Bertrand M. suggested moving to proposal so > that developers can post comments on the proposal page. > > > So now, the smart message is in. > > But so long you store it in some internal opaque format, > > then should the API furnish finer handling of it. > > No, I don't think so. I thought of using the Config package, but since > the state file is completely internal to the program and should never be > modified by an end user, a simple tab-delimited file should suffice. > > > 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. > > Once the state has been cleared, alerts will only be sent if there is a > problem. > > On a side note, an end user can run multiple monitoring sessions and > keep track of multiple states by using > Net_Monitor::setOptions(array('state_file' => 'SomeNewFileName')) for > each new session. > > Clearing state altogether is just an optional feature that might be > useful in some circumstances. > > > 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. > > > 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. > > > I think this save format is quite dangerous. > > What format do you think would be more safe? I would sugest a serialized array instead. This would also make it easier to remove a single service. [snip] -- Justin Patrin

« previous php.pear.dev (#34851) next »