On Fri, 2010-01-29 at 12:20 -0500, Mossman, Paul AVAYA (CAR:9D30) wrote: > Arjun wrote: > > Scott Lawrence wrote: > > > On Fri, 2010-01-29 at 15:47 +0200, Cristi Starasciuc wrote: > > >> Hi, > > >> > > >> Regarding an older issue: > > http://track.sipfoundry.org/browse/XX-6702 > > >> - Changing greeting type via IVR wipes out IMAP information in > > >> mailboxprefs.xml > > >> > > >> It was decided that sipXconfig would not generate mailboxprefs.xml > > >> anymore and move email/imap information in validusers.xml. > > >> > > >> Damian commited a change for this issue in late October 2009, but > > >> left the issue open with a comment that "sipXconfig/sipXivr still > > >> need to exchange information about voicemail prompt". > > >> > > >> I have decided (and it was agreed by Damian) to create a > > sipXconfig > > >> REST interface that would get/set the active greeting. > > Right now in > > >> sipXconfig the activegreeting is kept as a user setting and I > > >> imagined sipXivr would use this REST to get/set the activegreeting > > >> (basically, it gets/sets the user setting in sipXconfig). > > >> > > >> However there's already a sipxIvr REST interface that does this on > > >> IVR side. > > >> > > >> Now I'm a bit confused. > > >> > > >> Do we really need this REST interface in sipXconfig? Or should > > >> sipXconfig just call sipXivr's REST to get/set the active greeting > > >> (get for displaying in UI, set for propagating the change > > to IVR). I > > >> see one problem here: if the IVR REST call fails for one reason or > > >> another, we risk having inconsistent values for the active > > greeting. > > >> > > >> The original sipXconfig proposal was to provide a REST > > interface for > > >> sipXivr to use whenever it wants to deal with active greeting > > >> (probably whenever it reads validusers.xml - which leads me to > > >> another > > >> question: why isn't the active greeting written in > > validusers.xml). > > >> > > >> Any clarification on this issue would be extremely helpful. > > > > > > I don't think that we have a clear definition of just what > > > 'validusers.xml' is for, and I think that we need one, but that's a > > > larger question. > > > > > > Individual services that have to manage per-user settings > > should not, > > > in my view, be making changes to a configuration file that's shared > > > across many different services. > > > > > > The voicemail application needs to store various settings and state > > > information about a user (beyond the actual voicemails > > themselves). > > > The fact that these are per-user information does not mean > > that they > > > belong in a global file that happens to have 'user' in its > > name. The > > > application should have storage under @SIPX_VARDIR@ (/var/sipxdata) > > > where it keeps things like per-user settings and audio files. > > > > > > In keeping with the general principles that 1) there should be the > > > minimum possible number of ways to do any one thing (just one is > > > best), and 2) data should be managed by the component that > > uses it so > > > that it will be local to that component when distributed: > > the sipXivr > > > voicemail application should provide the API that allows the user > > > portal or the management application (which will eventually be > > > separated) to manipulate the per-user data. > > > > > > > I would prefer if sipXconfig provided the REST service and > > sipXivr be its consumer. SipXconfig can then write this > > setting out to a config file (e.g. validusers.xml), from > > where sipXivr can pick it up. The main advantage of this is, > > it would allow users to make configuration changes when > > sipXivr is not running. And, the disadvantage being, no > > configuration changes are possible when sipXconfig is not > > running - but I think that is an acceptable shortcoming. > > +1 > > Configuration data should be mastered in sipXconfig.
Manage it in sipXconfig if you want to, but that does not imply that it should be a part of validusers.xml - that thing is turning into a grab bag. _______________________________________________ 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/
