* [sup-talk] updated xapian experimental branch
@ 2009-11-01 23:42 Rich Lane
2009-11-02 12:08 ` William Morgan
0 siblings, 1 reply; 6+ messages in thread
From: Rich Lane @ 2009-11-01 23:42 UTC (permalink / raw)
To: sup-talk
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@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [sup-talk] updated xapian experimental branch
2009-11-01 23:42 [sup-talk] updated xapian experimental branch Rich Lane
@ 2009-11-02 12:08 ` William Morgan
2009-11-03 3:48 ` Rich Lane
0 siblings, 1 reply; 6+ messages in thread
From: William Morgan @ 2009-11-02 12:08 UTC (permalink / raw)
To: sup-talk
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@masanjin.net>
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [sup-talk] updated xapian experimental branch
2009-11-02 12:08 ` William Morgan
@ 2009-11-03 3:48 ` Rich Lane
2009-11-03 8:39 ` Nicolas Pouillard
0 siblings, 1 reply; 6+ messages in thread
From: Rich Lane @ 2009-11-03 3:48 UTC (permalink / raw)
To: sup-talk
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@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [sup-talk] updated xapian experimental branch
2009-11-03 3:48 ` Rich Lane
@ 2009-11-03 8:39 ` Nicolas Pouillard
2009-11-03 16:12 ` Rich Lane
0 siblings, 1 reply; 6+ messages in thread
From: Nicolas Pouillard @ 2009-11-03 8:39 UTC (permalink / raw)
To: Rich Lane; +Cc: sup-talk
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [sup-talk] updated xapian experimental branch
2009-11-03 8:39 ` Nicolas Pouillard
@ 2009-11-03 16:12 ` Rich Lane
2009-11-03 16:15 ` Nicolas Pouillard
0 siblings, 1 reply; 6+ messages in thread
From: Rich Lane @ 2009-11-03 16:12 UTC (permalink / raw)
To: Nicolas Pouillard; +Cc: sup-talk
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@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [sup-talk] updated xapian experimental branch
2009-11-03 16:12 ` Rich Lane
@ 2009-11-03 16:15 ` Nicolas Pouillard
0 siblings, 0 replies; 6+ messages in thread
From: Nicolas Pouillard @ 2009-11-03 16:15 UTC (permalink / raw)
To: Rich Lane; +Cc: sup-talk
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@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-11-03 16:15 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-11-01 23:42 [sup-talk] updated xapian experimental branch Rich Lane
2009-11-02 12:08 ` William Morgan
2009-11-03 3:48 ` Rich Lane
2009-11-03 8:39 ` Nicolas Pouillard
2009-11-03 16:12 ` Rich Lane
2009-11-03 16:15 ` Nicolas Pouillard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox