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? ;-) 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 can of change course, and reach your own conclusions, but that was the reasoning behind adding the RESTful interfaces into sipXivr, and ripping out the direct manipulation of mailboxprefs.xml by sipXconfig. --Woof! _______________________________________________ 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/
