Scott Lawrence wrote: [...]
>> I suspect sipXconfig implementation would be simpler if sipXalarms were to >> be separated from sipXsupervisor. At the moment we have a special case for >> configuring alarms in the sipXconfig code and it has already caused several >> issues (recently: http://track.sipfoundry.org/browse/XX-6970). >> It's not directly related to adding alarm functionality but it seems we >> would be adding even more config files for alarm service, which is trivial >> if this is a 'normal' service and complicated if it's a sipXsupervisor. > > 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. _______________________________________________ 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/
