Bug 201974 - [performance][api] Support Lazy Population of Views and Tables
Summary: [performance][api] Support Lazy Population of Views and Tables
Status: ASSIGNED
Alias: None
Product: Target Management
Classification: Tools
Component: RSE (show other bugs)
Version: 2.0   Edit
Hardware: All All
: P4 enhancement (vote)
Target Milestone: Future   Edit
Assignee: dsdp.tm.rse-inbox CLA
QA Contact: Martin Oberhuber CLA
URL:
Whiteboard:
Keywords: api
Depends on:
Blocks:
 
Reported: 2007-08-31 18:57 EDT by Michael Y Kwong CLA
Modified: 2008-11-12 08:52 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Y Kwong CLA 2007-08-31 18:57:47 EDT
Make use of Virtual Tables and Trees and enhance the RSE protocol to allow lazy population of these widgets.  This could be very useful when a huge number of artifacts need to be handled by RSE.  While filters help in those scenarios, it is sometimes awkward to have to define new filters just to make the UI responsive.

http://www.eclipse.org/articles/Article-SWT-Virtual/Virtual-in-SWT.html
Comment 1 Martin Oberhuber CLA 2007-09-03 11:55:19 EDT
This is a good, but not easy to implement enhancement request.

I think the main work item would be to come up with an API that extends ISubSystem.internalResolveFilterString() such that the client can ask for a maximum number of items to retrieve as well as a start index for items to retrieve.
The subsystem would then return the given maximum number of items, plus an indication of how many items the query would resolve if all were resolved.

Given that each query of additional items requires an additional client - server turnaround, I think there is a need for caching of retrieved subsets, and perhaps further optimizing the retrieval protocol. 

If I'm not mistaken, this general problem is one of the core problems that the Platform/Debug team and the Device Debugging Project (DSDP-DD) are working on. These two project should be considered for implementation ideas when addressing this.

Currently I see no resources for working on this.
Comment 2 Martin Oberhuber CLA 2007-09-19 10:43:01 EDT
We discussed this, and it partial retrieval of data is the main crack of this. We think that API for this can also be added later in a backward compatbile manner.

Some ideas:
 a) Query a maximum number of data. The maximum number would be a "hint" that 
    can be observed by services or not. One problem might be inconsistencies
    when retrieving different part of data at different times.
 b) Stream-like retrieval of data. Starting to update the UI while transfer is
    still ongoing. Canceling the transfer when enough data is available or user
    is interested in something else.

This is an interesting issue but out of scope right now, so we keep it deferred and decrease priority.