|Re: [p2-dev] iterators, queries, and collectors....oh my!!|
Hi, Ian, Thomas and others:
I've been commenting in various bugs on this topic, but I feel like my intent gets lost with comments sprinkled around bugs that are discussing very specific parts of the API.
I think we need to look collectively at the problem of remote queries, large data sets, filtering, etc.
Specifically, I think we need to define and implement queries for the routine tasks that are causing complexities in the collectors themselves, before defining a solution for async collectors.
This also helps more generally with the ability to optimize queries later on, as Thomas points out in https://bugs.eclipse.org/bugs/show_bug.cgi?id=256412.
I think having done this work, most collectors will simplify to doing nothing or possibly just wrapping the results (as the UI does). At that point, a pluggable acceptor might work (not sure).
Ideally, I'd hope that a collector would not need to operate in a special async mode.
>From the UI point of view, these queries are needed:
- latest version of an IU
- categories (this is really just a property query)
- IU's in a particular category (that also satisfy a UI visibility property query)
- IU's that are not categorized (that also satisfy a UI visiblity property query)
- IU's that pattern match a string
That last one would solve most of my pain with regards to lazy repo loading and filtering. If we can push pattern matching to the queryable side where it belongs, the UI would have no need to force a full iteration of all repos in special cases.
p2-dev mailing list