Paul Mossman wrote: > Hi all, > > The auto-provision feature currently constructs Polycom config file > content from code, without the use of templates. It's pretty basic > right now, and effectively duplicates template content in sipXconfig. > > I'd like to start using the sipXconfig Polycom templates. I can't find > a good reason to involve the running sipXconfig instance in this. The > current plan will simply be to use Velocity and the templates from > /etc/sipxpbx/polycom/ directly.
Using those files means that you have RPM dependency on sipXconfig. And that you need to worry about how those files are changed or moved. May it's time reconsider the idea or reusing auto-provisioning groups (and extend/buiod sipXconfig auto-provisioning instead of building a parallel system). In that way admins can configure patterns for new devices reusing entire sipXconfig machinery. And all changes and updates to plug-ins will be picked up automatically. > > I have a hunch that it may also be useful to re-use a couple sipXconfig > classes. If so, I certainly wouldn't do anything that reads or writes > from the database. > > Any objections and/or guidance? Thanks. > Using any classes from neoconf directly can easily turn into maintanace nightmare. The only safe way of implementing this would be to have a service (or a library) that can generate profiles for devices from some kind of uniformly formated data (provided either by sipXconfig or your auto-provisioning service). I'd really like to end up with a system that can be enhanced for various protocols and devices. I feel - possibly unfairly - that this feature hijacks us into Polycom territory. D. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
