Re: gnus and imap

[David Engster <deng@randomsample.de>]

Vitaly Mayatskikh <v.mayatskih@gmail.com> writes:
>> Absolutely. The problem is that active information is used throughout
>> Gnus, and the code is in parts already pretty convoluted, especially the
>> ones dealing with updating groups and checking for unread messages. I
>> guess that putting unread information in gnus-info would affect fewer
>> parts of the code.
>
> 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.

By the way, the reason for generating a partial active file for nnimap
is simply speed. Scanning every single group is slow (this is what
gnus-group-get-new-news-this-group does - it's much slower than just
gnus-group-get-new-news). See this thread for an explanation:

http://thread.gmane.org/gmane.emacs.gnus.general/26128/focus=26762

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

,----
| gnus-request-group-articles is a compiled Lisp function in `gnus-int.el'.
| (gnus-request-group-articles group)
| 
| Request a list of existing articles in group.
`----

This function calls a back end function
*-request-group-articles. However, this is currently only implemented
for nntp.

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.

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.

BTW, there was also a patch for this, though for nnml, but it was not
integrated into Gnus:

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

The comments on this are interesting, especially the ones from Kevin
Greiner, which led me to the above request-group-articles function.

>  By the way, have Gnus developers any plans of doing large changes in
> Gnus, like refactoring, global cleanup, etc?

Not that I know of.

-David