We're hoping for Beta for community version Just before CoLab. On Mon, Jan 9, 2012 at 10:31 PM, Todd Hodgen <[email protected]> wrote:
> Thanks for the comments Douglas. SipXKickstarter sounds appropriate. > > I think you have clarified a lot already. > > Starting a new plugin, which is written off the back of the old one might > make sense so that it doesn't have to start from the beginning? The big > thing is the past you had to define all of the missing parameters, now you > just have to change the ones you don't want set to default is my > understanding. There is a conversion tool that can be ran on current files > to make them compatible with the new version also. > > I've ran it on some files, there is an error in the [mac]-sipx-sip file. > I'm trying to find it this evening for another project I am working on. > > There were some file changes several releases ago wrt the Polycom files. > That split caused there to be files supported by the newer phones, yet not > supported by the older 300, 500, 600 phones - the original lot. I don't > recall the details, or who from, but my understanding was it was hastily > put > together to get support out for the new phones. It might be just fine, and > doesn't need to be address if there will be a new plugin I suspect. Maybe > the plugin takes in all phones that work on the new file structure. > > I like the new structure with Git, that should help to break projects down > a > bit, and allow for greater contribution from the Community I suspect, as > well as allow Commercial entities like eZuce to customize their individual > offerings. > > It will be interesting to see this at Hackfest. > > Douglas - just an estimate - do you envision 4.6 being released after > CoLab, > or prior to it? Or during it maybe? > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Douglas > Hubler > Sent: Monday, January 09, 2012 6:21 AM > To: Discussion list for users of sipXecs software > Subject: Re: [sipx-users] Polycom Support for 3.3 + and VVX500 and other > next gen phones > > On Mon, Jan 9, 2012 at 3:31 AM, Todd Hodgen <[email protected]> wrote: > > Developers – There needs to be a broad discussion about support for > > Polycom version 3.3 and beyond, as well as support for the next > > generation phones they have or are releasing in 2012. The first phone > > – the VVX500 is out now, and not supported within sipXecs. > > > > > > > > This email is not to start the development of that software, but to > > have a discussion about methods of architecting support for it, and > > then implementing that support. > > > > > > > > As far as implementing that support, I will be trying a new effort to > > build this support in by asking the members of the community to invest > > in its support. In time, I will start a campaign to begin development > > of a fund for members of the community that want this support to get > > involved in development of it by assisting in the funding of it. > > This will be a first for this project, and hopefully the beginning of > > more projects like this to come. > > sounds interesting. sipXkickstarter ;) > > > Here are the issues to consider, and please add if you are aware of more. > > > > > > > > Polycom 3.3 requires substantial rewrites of code to be supported. > > The new files no longer require the inclusion of all of the default > > information, but rather now require changes from the default to new > > values. The two versions are not compatible, so method needs to be > > designed to keep the files separate within their directories, and the > > phones need to be able to select what directory they look for their files > in – or some similar method. > > > > > > > > What really needs to be decided is how this will best take place, to > > conform to best practices of today, and future of sipXecs. > > If the files are so different, we should start a whole new plugin > implementation. Details of which can can decided during implementation. > > > > > Polycom has created a v3.2.x or earlier conversion tool which can be > > used to make older files compatible with 3.3 file structure. It > > seems pretty straight forward, and appears to work for the most part > > (not completely) but the base files within sipXecs needs to be changed > > to follow this new file structure if sipXecs is going to continue to > > manage Polycom Phones. It is only a matter of time before new phones > > start shipping with the newer firmware, and the issue begins to compound > itself. > > > > > > > > I understand some work needs to be done to clean up the previous file > > structure changes by Polycom, which were apparently done in a quick > > and not entirely desirable fashion. > > Could be, but I'm not aware of the the issues here. Can you elaborate? > > > > I’d like to see this thread stay on the task of discussion ideas on > > how to move forward with the architecture of supporting these various > > versions, so we can make progress towards the building of a plan so we > > can get a developer started on this work. I believe we have an > > outside resource identified, that is familiar with some of the dev > > team, but need to start with some direction to get thing moving forward. > > > An ENORMOUS leap toward this will be available in 4.6. Namely being > able to customize, contribute, build, fork, hack on a particular support > for > a device outside of the core of sipXecs. I can give a lot more details > about this at CoLab, but for example here is the actual source code for > polycom phone support for 4.6 > > > https://github.com/dhubler/sipxecs/tree/master/sipXpolycom > > The source is part of sipXecs github repo, but that really just to make > branching and tagging easier. The source can live in a separate github > repo > if folks need that. > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > -- Michael Picher, Director of Technical Services eZuce, Inc. 300 Brickstone Square**** Suite 201**** Andover, MA. 01810 O.978-296-1005 X2015 M.207-956-0262 @mpicher <http://twitter.com/mpicher> www.ezuce.com ------------------------------------------------------------------------------------------------------------ Hope to see you at the sipX CoLab! http://www.sipfoundry.org/sipx-colab A gathering for - open source users, eZuce customers & eZuce partners Get the inside track on 4.6 and a glimpse at the future of sipXecs!
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
