Subject: Re: [sup-talk] updated xapian experimental branch

From: Rich Lane <[email-masked]>
Date: Tue, 03 Nov 2009 11:12:11 -0500

Excerpts from Nicolas Pouillard's message of Tue Nov 03 03:39:48 -0500 2009:
> 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?

is:inbox OR foo

We have to use xapian to check relevance here because of the fulltext
term 'foo'.
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: Rich Lane <[email-masked]>
Date: Sun, 01 Nov 2009 18:42:38 -0500

I've pushed a few more commits to http://github.com/rlane/sup/tree/experimental

The major feature on this branch is the immediate label updates I've
mentioned before on the list. The bulk of the actual changes are
basically consequences of this feature:

Use of Xapian for thread relevance checks
 - Instead of hardcoding the policy into InboxMode
 - 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
  - Saves us from (half of the) adding/removing threads changes cursor_thread problem
 - Relevant messages added to thread-index-modes without reload

Async message state saving
 - Keeps the UI responsive
 - Prepares us for a sup-server future

Fallout from async message saving
 - UpdateManager messages handled in main event loop
  - Avoids many races but can lag UI unless we're careful

New, simpler undo implementation
 - Still needs work at a few use-sites to be completely correct

Let me know what you all think of these changes. I'll need to do a lot
of rebasing before this branch is clean enough to be merged.

A couple of bugs I know about:
  - Discarding drafts is disabled
  - Occasionally, new messages in an existing undisplayed thread fail to
    get added to the ThreadSet. I haven't been able to come up with a
    test case for this, so if someone wants to give that a shot it would
    be very helpful.
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: William Morgan <[email-masked]>
Date: Mon, 02 Nov 2009 04:08:09 -0800

Reformatted excerpts from Rich Lane's message of 2009-11-01:
> mentioned before on the list.

Awesome, really awesome.

>  - Instead of hardcoding the policy into InboxMode

Awesome.

>     events is difficult with the current UI code

Can you describe this a bit?

>   - Avoids many races but can lag UI unless we're careful

I think this is a great idea.

Thanks for all of this, Rich.
-- 
William <[email-masked]>
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: Nicolas Pouillard <[email-masked]>
Date: Tue, 03 Nov 2009 09:39:48 +0100

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:
> 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.

-- 
Nicolas Pouillard
http://nicolaspouillard.fr
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: Nicolas Pouillard <[email-masked]>
Date: Tue, 03 Nov 2009 17:15:23 +0100

> We have to use xapian to check relevance here because of the fulltext

Hum... Right. This is because we don't want to look into the fulltext of
the threads we have... this does makes sense.

---

From: Rich Lane <[email-masked]>
Date: Mon, 02 Nov 2009 22:48:10 -0500