Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] iterators, queries, and collectors....oh my!! 
Hi Susan,

>Happy New Year, everyone....
>
>Can someone point me to the bug number with the IFutureStatus proposal?
>I was expecting to find it in https://bugs.eclipse.org/bugs/show_bug.cgi?id=256435, but it's not there. 

Happy New Year to you (and all p2ers out there as well).

The bug is here:  https://bugs.eclipse.org/bugs/show_bug.cgi?id=253777
Note it's migrated a little bit...i.e. it's now called just IFuture rather than IFutureStatus...and I'm right now working on a new attachment based upon further feedback from Pavel and Jeff....but the IFuture contract is beginning to get more stable, I think. 

Scott


Susan Franklin McCourt wrote:


Happy New Year, everyone....

Can someone point me to the bug number with the IFutureStatus proposal?
I was expecting to find it in https://bugs.eclipse.org/bugs/show_bug.cgi?id=256435, but it's not there.
As far as the semantics of layered pattern matching...I think it would largely depend on the UI setting the right expectation for the user. If there was only one filter box and the user first typed SDK and then EMF, I would see that as a new filter on EMF only. Simply because that is how the filter box works everywhere else in Eclipse.
If instead you wanted to allow client-side filtering of server results, then I think it's a UI design question. I don't think the user necessarily cares who is doing the filtering (the client or the server), but it is a "cumulative filter" which would need to be represented differently. I don't think this affects the API of the underlying queryable mechanism - I'm not suggesting that the queryable should have any special notion of filtering queries or having sequential/cumulative queries to support this. 

susan
Inactive hide details for "Ian Bull" <irbull@xxxxxxxxxxxxxxxxx>"Ian Bull" <irbull@xxxxxxxxxxxxxxxxx> 



	

                        *"Ian Bull" <irbull@xxxxxxxxxxxxxxxxx>*
                        Sent by: p2-dev-bounces@xxxxxxxxxxx

                        12/30/2008 04:42 PM
                        Please respond to P2 developer discussions

	

To: "P2 developer discussions" <p2-dev@xxxxxxxxxxx>
cc:
Subject: Re: [p2-dev] iterators, queries, and collectors....oh my!!


      This is a great usecase. In the IFutureStatus proposal there is
      hasNext() and isDone(). Does this capture the situation from an
      API point of view? (i.e., is mightHaveNext() equivalent to
      !isDone())? I don't think the current FutureStatus impl has the
      desired semantics for this case but clearly something could be
implemented. 

Regarding filtering, does anyone have thoughts on the following scenario:
Say I have a query that looks for IUs that are SDKs (they have SDK in their name or something), and I invoke this query. (it may go across the wire, it doesn't really matter). As this starts returning results, I start to populate a list.
Then I filter the list (looking for the EMF SDK I type EM). Does it make sense for this to be a new query (look for SDK's + name contains "EM"), or should we have a "filter" on the query results. So I can say, ok, as these results come in, only give me back ones that contain EM. Then, if I type EMF, it has all the results, and it just does a different filter.
So essentially, should we have "pattern match" or simply "filters" on query results? 

cheers,
Ian


--
R. Ian Bull, PhD
Software Developer, EclipseSource_
__http://www.ianbull.com_ <http://www.ianbull.com/>_
__http://blog.ianbull.com_ <http://blog.ianbull.com/>_______________________________________________ 
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
------------------------------------------------------------------------

_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev

Back to the top