>> I don't see what the problem is with the above; integrating the alarm
>> monitor into sipXsupervisor. The particular issue you cite seems easy >> to me - the replication of that file happens through sipXsupervisor >> anyway; it should be able to notice that fact and reload the >> definitions without any other prompting. >> >It is a problem: sipXsupervisor cannot be started or stopped like other services (because it's doing starting and >stopping): it needs to be treated differently. >sipXsupervisor detecting changes to its config files would not solve anything. Part of the problem - uncaught be testing >yet - was that sipXconfig did not push all the files to a newly added host. >D. Please suggest which is a optimal design choice keeping in mind the size/scope of snmp monitor task: 1.Implementing snmp alarm monitor into sipXsupervisor & taking up the promotion of alarm server into normal service as separate task later. Or 2.Promoting alarm server into service first & put the snmp monitor functionality into the new service. Thanks, Seshu _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
