updated xapian experimental branch

[Rich Lane]

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
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[William Morgan-4]

Reformatted excerpts from Rich Lane's message of 2009-11-01:
> The major feature on this branch is the immediate label updates I've
> mentioned before on the list.

Awesome, really awesome.

> Use of Xapian for thread relevance checks
>  - Instead of hardcoding the policy into InboxMode

Awesome.

>  - 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?

> Fallout from async message saving
>  - UpdateManager messages handled in main event loop
>   - 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 <wmorgan-sup@...>
_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Rich Lane]

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.
_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Nicolas Pouillard-2]

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@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Rich Lane]

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
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Nicolas Pouillard-2]

Excerpts from Rich Lane's message of Tue Nov 03 17:12:11 +0100 2009:
> 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'.

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

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