On Thu, 2009-11-12 at 16:03 -0500, Andy Spitzer wrote: > Woof! > > On Thu, 12 Nov 2009 15:09:18 -0500, Scott Lawrence > <[email protected]> wrote: > > > Each service should manage its own configuration and its own service > > storage. > Agreed. > > > MoH and Voicemail are two different services. > Disagreed. Violently. MoH and Voicemail are too different FEATURES. > They happen to both be implemented in the same executable (sipXivr), with > the same requirements (FreeSWITCH, validusers.xml, access to user mailbox > filesystem, etc.). That makes them the same SERVICE, and they are part of > the same ROLE and cannot be torn asunder. > > Previously when MoH was implemented in the same executable as the Park > Server (sipXpark), that did NOT mean that the Park Server and MoH were two > different SERVICES. They lived and died as one. They were configured as > one. > > Now that MoH split from sipXpark has moved in with sipXivr, she has gained > some personal storage requirements (just like, um, VoiceMail), and there > is no reason not to treat them as one. The service (sipXivr), happens to > perform a number of different Features, that may or may not be related. > Just like in the past AA and VM were the same service (sipXvxml), they are > today the same service (sipXivr), and now MoH has moved in with them too > (ooh, a threesome!). It just makes sense from a logicial and physical > point of view that calls to the IVR service end up using the same > executables. To do otherwise would add complication for no gain. > > If tomorrow they get a divorce and all three end up in separate > executables, so be it. THEN the configuration can be split up and carved > up and moved around. But that is then, and this is now. Let them live > together in peace.
That's a pretty good case, but I'd like to point out that the only thing presently keeping us from making the IVR feature and the MoH feature highly available by configuring multiple redundant/load-sharing instances of them is exactly that they share storage with the voicemail service. _______________________________________________ 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/
