Re: Re: Working Version of Net_Monitor - Please Review :)
| From: | Justin Patrin | 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