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/
