On Wed, May 14, 2008 at 1:07 PM, Andy Spitzer <[EMAIL PROTECTED]> wrote: > Woof! > > On Wed, 14 May 2008 11:51:09 -0400, Carolyn Beeton <[EMAIL PROTECTED]> wrote: > >> As the main pusher for alarms would this not be an example where the >> application code could raise an alarm, which would then be logged and >> emailed to contacts?
In the context of sipxbridge, an alarm would be useful when, for example, you could not REGISTER with an ITSP account or authentication failure occured during call setup. > > Alas, probably not. The reason being the application has to have enough > information to know how to raise alarms--information that is most likely > contained in its configuration! As the trouble was the configuration was > corrupted, there would be no way for the app to know how to raise alarms. > > However, if my previous advice was taken and STDERR was used as the output of > last resort, then it becomes the parent process' problem to read STDERR and > report that via logging and possibly an alarm (along with the fact that the > process keeps exiting, of course). I will log the Error to stderr and we can take it from there. This would be useful in extreme situations such as if the user accidentally wiped out a library and the process is unable to start. Thanks Ranga As all processes in sipXecs can write to STDERR no matter what language they are written in, it would reduce the need for alarm libraries in various languages. > > > --Woof! > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
