Bug 226343

Description Susan McCourt 2008-04-09 14:46:42 EDT

I have spent more time than I wish trying to make DeferredTreeContentManager work well with the p2 UI.  It seems to work for very specific kinds of content providers, but of course the successful patterns have to be discovered through trial and error. 

The main issue is that it has timing problems that can cause duplicate children to be added.  When children of an element are requested, it is set up to cancel any pending/running jobs for the same element.  But if a fetch was previously requested and has already completed, it simply fetches again and accumulates the results in the viewer.  The result is duplicate entries, one duplicate for each fetch that completes before the next one is requested.  

Ok, so we can say that content providers (or model elements) must know when the deferred fetch is actually necessary, by caching something that lets them know not to use the manager.   The problem is that the manager's listener for a finished update job doesn't provide any info to let you know which fetch job finished, so if you wanted the content provider to keep track of information like this, you don't have a reliable way to do it.  (There is also a bug in the update job listener itself, reported in bug #226366).  The listener as implemented is only really useful if you have one monolithic initialization sequence and you just want to know when it's done.

The p2 model is more like CVS, where expanding each element could potentially cause another fetch job, so you need to know about each job.  CVS doesn't have the problem we do, because they do some caching on the element side, so
that if something has been fetched previously, they never go to the manager.   In p2's world, the caches for remote access are in the (true) model, and UI code doesn't really know if it will take a long time or a short time to get the information.  The end result is that if it takes along time to get the children of element A, and someone else requests the children for element A during this time, the job gets cancelled and a new one started.  But if the fetch for A completes just before the request for the children of A is received, then it just fetches again and adds multiple items in the viewer.

You could argue that the UI should be smarter, eliminating these redundant requests for children, but these requests were coming from places like viewer filters which get attached to the viewer without the model elements necessarily knowing anything about it.

Bottom line:  at a minimum the documentation should be improved and bug #226366 fixed.   Once I discovered all the things that were going wrong, I ended up hacking a subclass for DeferredTreeContentManager that provides element-based listeners  (starting fetching for A, ending fetching for A), and this allowed me to add the caches necessary to prevent the duplicate updates.