Hi, Sorry about the TODOs, they were TODO tasks but I forgot to erase some when I finished that task. I'll go and explain the functions in more detail, and deal with commented out codes. I will also go and fix the ResourceList::resourceChanged() function so that it will also check the nameXml for changes.
The algorithm for comparing the resource-lists will first create single linked lists from the resource-lists in the XML(xmlList) and the RLS(rlsList) using the user-part as the node. Then it will compare between xmlList and rlsList. If a user-part is found in both xmlList and rlsList, those will be saved in a third single linked list(similarList) and will be removed from xmlList and rlsList so that xmlList and rlsList will only have user-parts that exists only in their respective list. If nodes exist in rlsList, then it means that resource-list should be removed from the RLS in order to match the XML. If nodes exist in xmlList, then it means those resource-lists will be appended in the RLS and all the resource-references will be inserted into the resource-list in the correct order in the RLS in order to match the XML. If nodes exist in similarList, then it is time to use an algorithm to check the resource-references in those resource-list to see if there are any changes, which is explained in the next paragraph. Note that if duplicate resource-lists exist in the XML then the latest version of that resource-lists will be in the RLS. The algorithm for comparing resource-references will first create single linked lists from the resource-references from a resource-list in the XML(rrXmlList) and the RLS(rrRlsList) using the uri-part as the node. Then it will compare between rrXmlList and rrRlsList. If a uri-part is found in both rrXmlList and rrRlsList, those will be saved in a third single linked list(rrSimilarList) and will be removed from rrXmlList and rrRlsList so that rrXmlList and rrRlsList will only have uri-parts that exists only in their respective list. If nodes exist in rrRlsList, then it means that resource-reference should be removed from the RLS in order to match the XML. If nodes exist in rrXmlList, then it means that resource-reference should be inserted in the right location into the RLS in order to match the XML and it also deletes that node from rrXmlList so that when a duplicate is found it will not insert that duplicate into the resource-list. If nodes exist in rrSimilarList, then it compare the resource-reference between the XML and the RLS. When comparing it checks if the display_name and the nameXml are the same between the XML and the RLS, it also compares what the previous resource-reference in the XML of the current resource-reference and checks if the previous resource-reference is indeed before the current resource-reference. If no changes were found in those 3 checks then nothing happens, but if a change was found that resource-reference will get deleted out of the RLS and inserted again into the right location with the new display_name and nameXml in the RLS. And for both scenarios, it also deletes that node from rrXmlList so that when a duplicate is found it will not re-update that duplicate into the resource-list. Note that when inserting a resource-reference into the RLS it inserts knowing what the previous resource-reference is based on the uri-part. If no uri-part of the previous resource-reference was given then the resource-reference is inserted at the beginning of the list. If a uri-part of the previous resource-reference was given and was found in the RLS then it inserts that resource-reference after the previous resource-reference. But if a uri-part of the previous resource-reference was given and not found in the RLS for some reason(say the previous resource-reference in the XML was a duplicate and was not added into the RLS) then that resource-reference is appended at the end of the list. Hope I did not miss anything out. I thought I should also explain the new algorithm for ResourceList::addResource too. Thanks, Hoa Nguyen On 7/22/2010 4:07 PM, WORLEY, Dale R (Dale) wrote: > 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/
