On Thu, 2008-10-23 at 14:04 +0000, Scott Lawrence wrote: > On Thu, 2008-10-23 at 09:41 -0400, Kevin Thorley wrote: > > On Thu, 2008-10-23 at 09:32 -0400, Damian Krzeminski wrote: > > > Scott Lawrence wrote: > > > > Currently the Configuration->Services page displays all the > > > > individual services (in some order): > > > > > > > [...] > > > > > > > > Some questions to consider: > > > > * Do administrators need to be able to be able to "explode" the > > > > group to see what's inside them even if they cannot control them > > > > individually? > > > > > > Yes. Also they need to have a way to access low level parameters in for > > > each service. > > > > Or, does a user not care what service a particular config param belongs > > to? When the service config params were on the System page, they > > weren't identified as belonging to a particular service. When I moved > > them to individual service pages I got some pushback, saying that it > > made it too difficult to know where to look. So, maybe we should be > > configuring these things at the group level. Of course there are things > > like logging that need to be configured at service level, but logging is > > a special case that probably needs to be handled separately anyways > > One thing to factor in when thinking about this: > > Some services have multiple instances. In some cases, the instances are > independent (multiple ACDs for example) and parameters in different > instances might have different values for good local reasons. In other > cases, the instances are not independent (replicated proxies and > registrars) and all parameters that are not specific to the instance > (like addresses) MUST be kept consistent. > >
Yes, but in the case of the UI layout you presented, any given page only displays the groups that are installed and running on a given server, correct? Are there any cases where more than one service of a type runs on the same server? Kevin _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
