Scott wrote: > > > * It places a greater burden on the management software to > > > maintain an internally consistent and usable configuration in > > > the database at all times. By separating the database from the > > > configuration used by the services, we allow the management > > > software (and administrator) to directly control how and when > > > configuration data is propagated to the live services. A series > > > of changes can be made in the database which, when complete, > > > form a new and useful configuration without worrying about > > > whether or not any intermediate state consisting of just some of > > > those changes is disfunctional. Many reconfiguration operations > > > consist of multiple steps, and it's easy to create situations in > > > which step 1 will break things until step 2 is done; by > > > separating the distribution and activation of configuration data > > > from the storage in the database, we have an obvious direct way > > > to control when the service 'sees' a new configuration, and can > > > improve the odds that it is internally consistent. > > > > I suspect that there are not many such cases. I certainly know of > > none for the applications that I am involved with. > > I can think of many, including in those applications. > Anything that changes how calls are distributed usually > requires some changes in multiple components, since > addressing and authorization are distributed in sipXecs. If > the proxy starts sending calls to a new ACD queue before the > ACD has been configured to accept calls at that address and > knows with agents are associated with it, then things are > going to go wrong pretty quickly.
Without getting into the mechanics of how the data exchanged, let's look at this case a little closer. In a perfect world: 1. How should sipXconfig, sipXproxy, and (the new) sipXacd co-ordinate to effect this configuration change? 2. How should deletion of an ACD queue be co-ordinated? -Paul [email protected] _______________________________________________ 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/
