On Fri, Feb 26, 2010 at 1:41 PM, Eric Varsanyi <[email protected]> wrote:
>
> 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.
>

+1 For this! Especially considering Eric is willing and able to do the
work. Perhaps a compromise could be reached in the form of an
'enable/disable hooks' option for troubleshooting.  I agree with Scott
as a matter of simplicity/consistency, but practically (real world) I
could see this as a huge benefit to the project in the long term by
lowering the barrier of entry for polycom customizations in general.
I would assume, over time, the best 'hacks' would be implemented into
the main phone config.

My $.02
_______________________________________________
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/

Reply via email to