Hi Woof! Good to hear from you :) Andy Spitzer wrote: > Woof! > > On Fri, Jan 29, 2010 at 1:15 PM, Paul Mossman <[email protected]> wrote: >> Why not put it in validusers.xml? That seems like the logical place for >> it. > > Because validusers.xml is potentially very large with thousands of > users, and changing it and replicating it due to change the USER makes > on a whim (not the admin) was deemed incorrect (by Damian and myself). >
Yep, I can see how it would be better to have a separate config file for these user-specific settings. > Another reason is because sipXecs is supposed to be able to be run > WITHOUT sipXconfig even there. Currently in sipXivr there is one > exception to that--a user cannot change her passcode from the TUI if > sipXconfig isn't up, but that's supposed to be a not very often event > (and the passcode is 'owned' by sipXconfig so it makes some sense). > > sipXivr is supposed to maintain it's own data, in an opaque format, > and sipXconfig (and portal) are supposed to request them from sipXivr, > not the other way 'round. > 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. We could come up with hacks around this handicap but, it would be nothing more than hacks. Ultimately, we need a model that we can reuse for other services as well. I think Peter's suggestion of using a common class to manipulate the data may be something worth looking at. But, I am not sure if that's really in scope for this release. > There are still many reasons sipXivr and sipXconfig/portal must live > on the same system, and removing them one by one is a good idea. > SipXconfig's direct reading/writing of mailboxprefs.xml was just one > of those (and it caused data to be lost), so it was to be replaced by > having sipXconfig use REST to read/update it via sipXivr. That > sipXivr doesn't have an https interface was just laziness on my part, > as it didn't need it (and thus by extreme programing principles it > wasn't done). By all means change that if you wish, but beware there > are still many other reasons the two must remain co-resident. > > --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/ _______________________________________________ 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/
