Snappy low-bandwidth nnimap, part II

Snappy low-bandwidth nnimap, part II

[David Engster]

[-- Attachment #1: Type: text/plain, Size: 1467 bytes --]

Last year I started the following thread:

http://thread.gmane.org/gmane.emacs.gnus.general/82121

In a nutshell: I was on vacation with a horrible mobile connection, and
nnimap kept doing those 'initial syncs', downloading hundreds of
kb. Nobody really knew what was going on, Lars only mentioned that it
was probably due to 'unexist' handling.

Since I'm doing my vacation at the same place this year, I just had to
debug this. Turns out it is indeed due to unexist handling using
QRESYNC. The problem seems to be this:

Say you have a group 'ding' and you refresh it on a QRESYNC-enabled
server. Gnus will look at the VANISHED answer and mark those articles as
'unexist'. However, if the group does not have any vanished articles,
the group's info will just contain '(unexist)' in its marks (hit 'G E'
to see it).

Now, when you enter this group and simply exit it again, you'll see that
this '(unexist)' range was deleted, which kinda makes sense because,
well, its an empty range, so why keep it? The problem is just that
nnimap-retrieve-group-data-early will now think this group was not
synced before and retrieve *all* flags instead of just the last 100,
which is what this 'doing initial sync' really means.

So the fix is pretty simple: Keep empty unexist ranges in the group's
info. The attached patch does that, but I'm not sure if this really is
the best solution, or if maybe this shouldn't be better fixed in
nnimap-retrieve-group-data-early?

-David


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: unexist-patch.diff --]
[-- Type: text/x-diff, Size: 452 bytes --]

diff --git a/lisp/gnus-sum.el b/lisp/gnus-sum.el
index aaed1d1..cab303d 100644
--- a/lisp/gnus-sum.el
+++ b/lisp/gnus-sum.el
@@ -6067,7 +6067,8 @@ If SELECT-ARTICLES, only select those articles from GROUP."
 			 (gnus-active gnus-newsgroup-name) del))
 	      (push (list del 'del (list (cdr type))) delta-marks))))
 
-	(when list
+	(when (or list
+		  (eq (cdr type) 'unexist))
 	  (push (cons (cdr type) list) newmarked)))
 
       (when delta-marks

Re: Snappy low-bandwidth nnimap, part II

[David Engster]

David Engster writes:
> So the fix is pretty simple: Keep empty unexist ranges in the group's
> info. The attached patch does that, but I'm not sure if this really is
> the best solution, or if maybe this shouldn't be better fixed in
> nnimap-retrieve-group-data-early?

I've used this change for a while and it seems to work fine, so I've
pushed it. Of course, if someone has a nicer solution, feel free to
change it.

-David

Re: Snappy low-bandwidth nnimap, part II

[Ted Zlatanov]

On Wed, 05 Jun 2013 18:46:55 +0200 David Engster <deng@randomsample.de> wrote: 

DE> David Engster writes:
>> So the fix is pretty simple: Keep empty unexist ranges in the group's
>> info. The attached patch does that, but I'm not sure if this really is
>> the best solution, or if maybe this shouldn't be better fixed in
>> nnimap-retrieve-group-data-early?

DE> I've used this change for a while and it seems to work fine, so I've
DE> pushed it. Of course, if someone has a nicer solution, feel free to
DE> change it.

Seems OK to me and there is no lynch mob outside the Gnus headquarters :)

Ted