Re: AlarmHandler as a daemon or service

[Maren Purves <m.purves@jach.hawaii.edu>]

Matthias Clausen wrote:
> Back from my trip to eclipsecon and my visit at SLAC - thanks to the 
> organizers of the little eclispe/XAL workshop I want to summarize where 
> we are with the alarm message approach.


> The messages will get written to the Oracle database by a message client 
> receiving the messages from the alarm message queue.
> - Point (4) on the to do list
> (This will be implemented in due time)

not sure we need or want an Oracle database here (I very
much agree with Andrei on this one). If this is optional
fine, but I wouldn't like it to be mandatory.

> Displaying messages from the (Oracle) archive
> Implemented in eclipse-BIRT - is one of the results of the eclipsecon!
>
> Displaying online messages:
> Open questions:
> - What shall the hierarchy look like?
> - How to configure the hierarchy? (using the existing alhConfig files?
> - How to implement acknowledge alarms?

and please don't have acknowledging mandatory ...
(in most cases we don't care whether there was an alarm some time in
the past. If the instrument isn't warming up nobody has to go and check
the compressor/chiller even if the temperature was above alarm limit at
some point)

> - What kind of filters are currently used/ necessary - or missing?
> - Point (5) on the to do list
>
> Alarm actions:
> What kind of actions are necessary?
> - Sending mail
> - Sending SMS messages
> - Send speech messages
> - Changing values on the same - or other - records
> - Point (6) on the to do list

I always liked the "you can make it do whatever you can write a command
for" feature, and I don't think I'd like that restricted. It's easy
enough to make it execute a shell script that does whatver the user
requires, no?

Aloha,

Maren