Scott Lawrence wrote: > On Wed, 2008-05-14 at 14:36 -0400, Dale Worley wrote: >> On Mon, 2008-05-12 at 15:37 -0700, Kevin Thorley wrote: >>> I have attached a patch for this issue that includes the necessary >>> changes to sipXproxy to get rid of sipXproxy-config.in. Can someone >>> please have a look at this portion? If all is well there, I will submit >>> everything to svn. I have also rebased the sipXconfig changes, so this >>> patch should apply on the current svn head. No need to install the >>> previous patch first. >> I do not see any mechanism for dealing with unexpected config items. If >> those cannot be accommodated, I fear that this change might make the >> system difficult to use for development purposes. > > No it won't - just don't start sipXconfig and you can do whatever you > want to >
To recap, the Jira issue (http://track.sipfoundry.org/browse/XCF-2441) for the issue in question only states that we should eliminate the sipXproxy-config.in file and have full control of that file handed over to sipXconfig. During the implementation of this issue, several related issues came up: 1) We need to address HA support. 2) We need to address upgrade and upgrade2mergedproxy support 3) We need a way to allow developers to still have some control over the configs without requiring changes in sipXconfig. With that in mind, we said we would address HA support after the sipXproxy-config support is in sipXconfig. We said the same regarding the upgrade support. As far as custom params (issue (3) above) we said the easiest option is to directly modify the velocity template (.vm). Admittedly, this does not handle the case where new parameters that are introduced need to be different on different hosts. At the current time, I do not see the need to have support for custom parameters that are different on different hosts. I feel that this will be a large amount of work and I haven't seen a use case to justify it. However, neither do I want to stand in the way of other developers that want to use sipXconfig, but also have the ability to manually change config files. So, my suggestion is to include a switch in sipxconfig.properties to fully disable the new config file replication. If this replication is disabled, then all config files will need to be created by hand and manually copied to distributed systems. Will this solution fit the current problem? 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
