OK, that looks like a good approach. There are a bunch of minor things that need work: - There are a number of places where "TODO" is seen -- are these really things "to-do"? - Some of the new routines are not well-explained in the .h files. The function descriptions seem to assume one knows the overall structure of the compare-and-change algorithm (which is not explained). - There are places where code is commented out. That is not good (and is not allowed by our coding guidelilnes). If the code is obsolete, delete it. If it is code to help the developer debug but would never be used in a production system, surround it with #ifdef.
More significant: - In ResourceList::resourceChanged(), the code should check the nameXml value as well. nameXml is included in the event notice, so we should make sure it gets updated if necessary. Can you describe the updating algorithm briefly? It is just complicated enough that we should include a prose description so the reader can verify that it will always achieve the desired results. I can help you with these. I am thinking of making a branch for holding these changes so that we can integrate improvements of minor issues in different checkins than we integrate the algorithm changes. The first step we need to worry about is getting a good description of the algorithm, so it is clear that the algorith always updates the RLS's list to match the resource-list.xml list. Dale _______________________________________________ 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/
