Re: [sup-talk] updated xapian experimental branch

From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Rich Lane <rlane@club.cc.cmu.edu>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] updated xapian experimental branch
Date: Tue, 03 Nov 2009 09:39:48 +0100	[thread overview]
Message-ID: <1257237468-sup-5663@peray> (raw)
In-Reply-To: <1257196293-sup-6882@zyrg.net>

Excerpts from Rich Lane's message of Tue Nov 03 04:48:10 +0100 2009:
> Excerpts from William Morgan's message of Mon Nov 02 07:08:09 -0500 2009:
> > >  - New 'z' key to clear irrelevant threads
> > >   - Not strictly necessary, but removing messages in response to index
> > >     events is difficult with the current UI code
> > 
> > Can you describe this a bit?
> 
> In general, we can only determine thread relevance by querying xapian.
> The actual write to the db is done async, so it will happen a little
> after you (for example) remove a label. The index fires a message event
> when the new state hits the db, and the UI then checks if the thread is
> still relevant to the query. So, the UI would only know to hide a newly
> irrelevant thread after the user has potentially gone on and done other
> actions. Having threads randomly disappear would be unfriendly, so
> instead the UI displays a red X. 'z' will drop these irrelevant threads.
> 
> For 'simple' queries we can determine relevance without xapian, so we
> could synchronously remove irrelevant threads in that case. However,
> this would lead to unintuitive situations where queries that appear
> similar have different irrelevance behaviors. The option that I will
> probably implement is choosing the behavior per-mode, so that inbox-mode
> could keep it's old behavior. That's the most important one anyway.

What are non simple queries which would cause 'red X's to appear? My guess
is that since we cannot change other attributes than the labels, we can
statically know if the thread is still relevant without the label. No?

-- 
Nicolas Pouillard
http://nicolaspouillard.fr
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk