Douglas wrote: > How can you judge what settings will never ever be used by > everyone who will ever use the system? As soon as you decide > "Demux Flag" is never used, some customer will need to change > it and then can't and entire configuration system is useless.
I see four categories of Phone settings: 1. Never useful. e.g. "SIP Settings in DHCP" (XX-5455), NAT, TCP Keep-Alive. The use cases for using these settings with sipXecs do not exist, or are at best far-fetched. The only effect that using them is likely to produce is to break the phone. I'd like to see them completely removed. 2. Almost never useful. e.g. tagSerialNo, Do Not Disturb, RTP filterByIp, URL dialing. You could contrive a use case for any of these. But having none are more important than simplicity. My hope is that these too will be removed, because I think our time is better spent elsewhere. But we can talk about it. 3. Useful, but only with the values dictated by sipXecs. e.g. BLF/MOH URI, NTP, SIP.allowTransferOnProceeding (XX-8030.) There is no need to expose these settings. They should be hidden. (Some can even be hard-coded in the template.) 4. Useful (often, or even only sometimes.) Let's do a good job on these. A really really good job. Good layout and labels. Useful help text. Appropriate GUI widgets. Intuitive and simple. > I do admit the way the settings are displayed it is > overwhelming. Yes. The current plug-in is very good at laying out settings in screens and sections that match the config file structure. But deviating from that, and you need to handle the layout-to-config mapping manually. You of course know more about how this works than I do. :) Ke Liu will be starting on the Polycom plug-in soon (XX-8261.) My advice for him is to identify the Category #3 and #4 settings, and concentrate on doing them well. Simplicity will require a manual layout-to-config mapping. That will be the challenge in keeping the Category #2 settings. Perhaps we can have some optional "Advanced" screens for specific Category #2 settings that any community users feel they need enough to provide a patch for? -Paul [email protected] _______________________________________________ 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/
