Re: gnus and imap

[David Engster <deng@randomsample.de>]

Vitaly Mayatskikh <v.mayatskih@gmail.com> writes:
>> I also further searched through gmane for the problem of wrong article
>> counts, since this topic came up frequently on the ding list. And lo and
>> behold, there's stuff already in Gnus for this, it's just not documented
>> in the manual.
>
> Wrong articles count is only one of problems. Getting old articles in
> nnimap group is close to impossible: I can't just tell "give me last 5
> old articles", because Gnus calculates wrong uids for these
> articles. Instead of it, I have to ask for last 1000 (or 10000, or
> 100000) articles :(

Well, this is a result of the wrong article count. Gnus simply uses

(- (1+ (cdr active)) (car active))

i.e. highest-lowest as the number of articles in a group. Since Zimbra
doesn't generate contiguous UIDs, this number is far too large. When you
tell Gnus to get the latest 5 articles, it simply queries the back end
with the UIDs from 'highest-4' to 'highest' - again assuming contiguous
article numbers. This is why you have to query Gnus with insane numbers
of articles, and of course this is slow, since the back end gets queried
with the fully expanded sequence.

> Also, I don't like any fixup hooks. Usually that means bad design of
> software, and usually they don't fix the problem at all.

At the moment, I see two options to get rid of this problem:

1) Make nnimap always return contiguous article numbers. Currently,
nnimap simply uses the UIDs provided by the IMAP server as article
numbers. We could change nnimap to use its own set of contiguous article
numbers and map those to the UIDs of the IMAP server.

The advantage would be that changes would be more or less confined to
nnimap, but this also implies that other back ends wouldn't profit from
this.

2) Make Gnus correctly deal with non-contiguous article numbers.

Obviously, all back ends would profit from this, but this would mean
(probably large) changes throughout the back end interface. We could use
gnus-request-group-articles to get a list of all article numbers in a
group (if the back end supports it). Gnus could calculate article counts
from this (total as well as unread) and also query the back end with the
correct sequence of article numbers.

Other options?

> I wish Gnus to cache all needed meta data, like other mail clients do. It
> is really not necessary to ask for all seen/unseen uids again and
> again, but rather to search uids since last update. 

Yes, caching would have to be done as well. We could use a new hash
table for this. There's one for the nnimap-fixup function anyway...

-David