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? > Id 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/
