Re: gnus and imap

[Vitaly Mayatskikh <v.mayatskih@gmail.com>]

David Engster <deng@randomsample.de> writes:

>> Yes, but we still have to fix all this convoluted code (for
>> gnus-unread-info or whatever). Unread articles calculations (count of
>> articles, list of articles) are totally wrong for the case of IMAP.
>
> I wonder why it's that bad with the Zimbra imapd. Doesn't it produce
> contiguous UIDs? I mean, I also get wrong article numbers with dovecot,
> but only in cases when I delete or move articles, but these are not
> "totally" wrong. As the documentation says, the number is an estimate,
> after all.

I have a lot of mail imported from another IMAP server, and, thus, have
two uid's spaces. Now my groups uids look like ((4000 . 30000) (100000
. 110000)).

>> It might be a good idea to extend api of back ends.
>
> 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 :(

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.

> We could implement this for nnimap and use it for the calculation of the
> unread count, and also for the calculation of the total number of
> articles in a group, which is also usually wrong in case of gaps in the
> article numbers. I think this is much easier to handle than extending
> gnus-active.

Yes, we need to delegate calculation of read/unread articles lists to
back ends (or implement these calculations correctly in Gnus for every
case).

> However, we should make this optional, since it will make IMAP access
> slower, which may be a problem for people accessing IMAP servers over
> slow lines. We should create a new server variable, something like
> 'exact-count' or something.

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. Currently, I simply
can't use Gnus with slow and unstable connection (gprs), because it
dies before Gnus finishes to update all my groups :) It is even hard to
update linux-kernel mailing list on 20mb link.

-- 
wbr, Vitaly