Good to know, I won't put any effort in the 'managed file' aspect then; its meeting my needs as is (just putting the additional config file into the chain in the top level template) and I don't mind staying on SVN indefinitely on this pilot system.
I'm still doing all the work for the ringtones and distinctive ring in speed dial directory, this is just an adjunct I put in to do the fancier stuff that will likely never get UI (unless Polycom themselves write it). Opinion/feature pitch: ---------------------------- Forcing users to do more dangerous/unmanaged things (stock answer on this list: "edit the velocity templates in /etc") to get the functionality they see in the polycom manual is not appealing. I understand the pressure should be to add the features to the UI properly and have them checked/managed. While it isn't hard, the learning curve and activation energy to properly add support to the sipxConfig framework is not something a casual user will do no matter how much he wants to use some feature of his phone. >From experience it is quite error prone to manually manage even a small stable >of polycom phones (10) using the 'edit the vm file' method. There are some >excellent and desirable features on the Polycoms that could be managed safely >by a knowledgeable user with just a little help from the infrastructure >(especially related to EFKs, like the OP). I expect that widespread use of a >feature via a raw polycom config hook would be a great indicator that the >feature deserves real UI attention while at the same time not blocking people >from using the feature and not burdening development with implementation of >every single thing in the polycom manual (for each release). Treating the >phones as unmanaged negates a HUGE aspect of the appeal of sipXecs and that >seems unacceptable as an answer. All this change was trying to do was provide a middle ground that requires a knowledgeable user but doesn't require getting over the hump of building your own distribution of sipXecs and helps you manage your customizations like other changes are managed. It is hidden as an 'advanced' option, maybe we could have a 'super secret advanced, taints your installation' style config setting :) ? Policy wise I'm not sure how this is any different than allowing unmanaged files in the tftp server via the UI. Why do you allow support of custom written files in general but disallow them if they are intended for a Polycom endpoint? -Eric On Feb 26, 2010, at 1:09 PM, Scott Lawrence wrote: > On Fri, 2010-02-26 at 12:35 -0600, Eric Varsanyi wrote: >> I'm working on some sipxconfig/polycom plugin changes that will let >> you supply raw polycom config by uploading a managed file and >> selecting that file from each phone (or group of phones). For phones >> with this attribute set the file is included in the top level list of >> config files in the 'root' config file (the one built for each mac >> address). I'm doing it to get the EFK and some fancy sound effects >> functionality (w/o writing pages of EFK related UI which seems over >> the top). >> >> This might help if I ever get it done and accepted :) > > Not to discourage you or anything, but the likelihood that we'd take a > change that allowed an externally produced phone configuration file to > be loaded or merged with one produced by sipXconfig is very very small. > There's no way to test such a feature, and while you may be competent to > use it, most who tried would not be. > > > _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
