Huijun Yang wrote: >> Kevin & Damian: Do you have input on my proposed changes, and > questions? >> Huijun has been already been investigating, and is ready to start > implementing the "overrides" approach, if we have > consensus. > >> Actually Huijun also found a challenge regarding default values that I > hadn't thought of. He'll post shortly with the > details. > > If we go for the proposed "overrides" approach, my concern is that we > will have to leave all the parameters blank without default values, and > let customer to configure/override whatever parameters he/she decides to > override the default value provided by Polycom in phone1.cfg or sip.cfg. > That way, we can generate a <mac>.cfg that only contains the parameters > customer configured. The problem of this approach is that customer will > not know what the default value for each parameter is, as phone1.cfg and > sip.cfg is not visible through web UI, all it has is a blank form in the > UI that contains hundreds of parameters without guidance on default > values. I would not like that if I am a customer. One way to solve this > issue could be that we load and parse phone1.cfg and sip.cfg provided > with the new firmware, and feed the default values to the UI, so that > customer will see all the default values being set, then when generating > the profile, for each parameter, we have to compare the configured value > with the default value from phone1.cfg and sip.cfg again, and only write > those parameters whose value changed into the profile... Not sure this > is an overkill and if we will run into any trap in this approach. The > other question is that how much we gain out of this?
I apologize in advance if I am missing something here... but can't we just define the correct defaults in the phone model file? That way the user will see the defaults as they are doing the configuration. This also gives us a way to check at config file generation time to see if we need to write a given parameter. Off the top of my head though, this looks like it would result in quite a few conditional checks in the velocity template, assuming we don't entirely re-do the way we generate the file. One issue with defining the defaults in the model file is that the most recent version of the defaults will always appear, which may or may not be confusing if an admin is configuring phones that are not up to the same version that sipXconfig supports. > > The other thing I want to comment is supporting different versions of > firmware. Currently, if you look the code, it assumes the firmware is > either 1.6 or 2.0. So it uses "unless=1.6" or "unless=2.0" to > distinguish parameters applicable for different versions. But that > approach will not work any more, as we now have 3.0, 3.1, and more in > future. First, I would question why we need to know the firmware version > at the first place. For new parameters introduced in newer version, my > understanding is that if the phone with old firmware does not recognize > them, the phone will ignore it. In other words, profile with new > parameters will not harm the phone with old firmware. Maybe my > understanding is not true? Your understanding is correct in theory. In practice, the config files for 2.x and 3.x firmware are close enough that we can use the same velocity template to generate them. We have different templates for 1.6 and 2.x because those files had significant differences. We had this conversation many times and did not come up with a great resolution... it is confusing from both a developer perspective and an administrator perspective to say 2.x when we really mean "all versions greater than 1.6". 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
