Martin Steinmann wrote: >>> It is conceivable that a given gateway be relied upon to serve more > than >>> one location. >> "Conceivable" is a metric that leads to the Dark Side. Is it >> "necessary" that we be able to this? I don't think so. >> > > This was actually a requirement for this feature: To implement source > routing so that gateways can be selected based on where the call > originates. Nothing was said about requiering that a gateway is > restricted to one location.
Nothing was said about requiring many other things. > > I am all in favor of simplification that makes it possible to get this > feature in. What we cannot do is introduce concepts that are hard to > understand and therefore negatively affect usability. I therefore think > that we have to go back and think about the original requirement and the > concept of introducing a location for gateways as well as assigning > users to such locations. Because everyone is very eager to throw "the requirement was this" and "the requirement was that" around (which probably does not make much sense to many people reading this list) I'd like to take this opportunity to remind everyone how things usually work in sipXconfig: Martin and users tell us to implement user stories / usage scenarios (in many cases I - or in this case Robert - write up stories bases on some initial request from the list or from Martin). We talk about stories on this list. We try to come up with a task list (list o JIRA issues). We proceed to implement the stories. I always push - and usually fail :-) - to implement the simplest thing that works first. Then we come back, look at the UI or a feature again. And we try to implement other stories. The goal is to have a quick turn around: try many things, get them better, stop early if we are heading in the wrong direction. During that time sipXconfig remains usable and people can look at it and provide more feedback. It's possible that the initial story does not get implemented in full. It's possible that more stories get implemented. We all - users and developers - learn more about the feature during the cycle. For various reasons things did not really work that well during 3.11 release: many changes in sipXconfig are related to sipXecs start-up phase and we had many problems getting system running reliably. But they worked relatively work during 7 or so earlier release cycles I was involved in this project and I'd like us to get back on track. So please try the feature. Tell us about configurations that you cannot support. Bring up unclear concepts. Propose solutions. I am not promising a perfect thing right away, but I am promising an ever-improving tool. D. PS. Do people think that keeping the stories on wiki referenced from road map is a good idea. Many other projects do that - check out Fedora wiki: http://fedoraproject.org/wiki/Releases/9/FeatureList I know we try to do it in JIRA but it's really not a good tool for that: we end up with really high level issues that never feel complete. D. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
