Andy Spitzer wrote: > Woof! > > On Fri, 29 Jan 2010 18:01:56 -0500, Arjun Nair <[email protected]> wrote: > >> There really is no perfect solution around this problem. On one hand, >> if sipXivr controls the data, then sipXconfig is dependent on it for >> manipulating that data. And on the other hand, if sipXconfig is the >> one controlling that data, then sipXivr is dependent on it for its >> full functionality. I would prefer the former approach, simply >> because, IMO, it's more probable that you'll get a system where >> sipXivr is disabled, than a system where sipXconfig is disabled and >> sipXivr is enabled. Plus, it adheres to our current model, where >> sipXconfig is the master of all data. > > Well, if sipXivr is disabled, what are users doing changing their active > greeting? ;-) >
Hehe, true.. I was thinking about it more from a situation where sipXivr was temporarily disabled for a short period of time (due to whatever reason). So during this period, we can either disallow all sipXivr related setting changes (completely understandable, cause sipXivr is down), or we can master all that data in sipXconfig and allow these changes, and replicate them in config files, which sipXivr picks up, when it starts up again. > Also, in this case it really isn't sipXconfig changing the active > greeting, it's the user portal (which just currently happens to live > inside sipXconfig). The user portal was to start using the sipXivr > RESTful interfaces for all access to voicemail information, (instead of > directly manipulating anything inside the mailbox directory, or directly > accessing POSTGRES) because it is supposed to be replaceable with other > interfaces (such as rich clients or widgets). This was the proposed > method of divorcing sipXconfig from sipXivr, and the way forward to > other types of voicemail interfaces to gain access to voicemail > information. > You are right, user portal just happens to live in sipXconfig, and shouldn't be treated as sipXconfig. But, that really is not an issue here, because we are not mastering the data in the user-portal. SipXconfig is responsible for it, the user-portal is just another consumer, similar to sipXivr. The question is more who should be responsible for this data. I am all up for accessing the voicemail information through sipXivr interfaces. But, this has to be read only information, or even some sort of action, like deleting voicemail, or moving voicemail between folders etc. These are actions that sipXivr is rightfully responsible for, and actions that cannot be stored and backed up in a database. However, settings on the other hand, like say what prompt the voicemail server should play, would be mastered by sipXconfig, and stored and backed up in the sipXconfig database. This is far from an ideal solution, and I do see the advantages of having sipXivr control it's own data, but I would still prefer this. Having said that, I am not married to it, manipulating the data through sipXivr would work fine as well.. Arjun _______________________________________________ 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/
