bug#20004: 25.0.50; nnimap should update unread counts from server

bug#20004: 25.0.50; nnimap should update unread counts from server

[Eric Abrahamsen]

At some point in the Gnus usage cycle, nnimap servers should be updating
their read marks (and possibly other marks) from the IMAP server flags.
Right now, Gnus relies on its own read/unread marks, and will not query
the server for group flags unless you manually delete the "active"
parameter for a group, and force it to re-scan the group.

This means that, if you have two or more Gnus installations accessing
the same server, they will get out of whack with each other, each
effectively assuming that its marks are canonically correct.

It also means that, if you have misconfigurations elsewhere (ahem), and
funny things are happening with your server flags, Gnus won't be aware
of that, leading to drift between Gnus and the server.

I'm not sure of the correct solution. Some possibilities:

1. Refresh flags on startup only (ie call
   `gnus-get-unread-articles-in-group' with the "update" flag set to t).
   This would be light on resources, but could still lead to confusion
   if you've actually got multiple Gnusii open and operating at the same time.
2. Constant refresh: flags are refreshed every time Gnus is refreshed.
   This seems overly resource intensive, though probably there could be
   a guard that first compares unread counts, and only does the full
   refresh if they differ.
3. Don't store unread marks for IMAP groups at all; only rely on the
   server flags (!)


I'm happy to contribute to a solution, depending on what the right
approach might be.

bug#20004: 25.0.50; nnimap should update unread counts from server

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> At some point in the Gnus usage cycle, nnimap servers should be updating
> their read marks (and possibly other marks) from the IMAP server flags.
> Right now, Gnus relies on its own read/unread marks, and will not query
> the server for group flags unless you manually delete the "active"
> parameter for a group, and force it to re-scan the group.

If you're talking to a modern IMAP server, then Gnus will issue QRESYNC
commands to the server and will get all new events that have happened.
This includes read/unread marks and all the rest.

If the server doesn't support that, there's not much that Gnus can do
without agressively re-requesting all the data on the server, and that's
going to be s-l-o-w.  So I don't think this is a bug.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#20004: 25.0.50; nnimap should update unread counts from server

[Eric Abrahamsen]

On 01/25/17 22:33 PM, Lars Ingebrigtsen wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> At some point in the Gnus usage cycle, nnimap servers should be updating
>> their read marks (and possibly other marks) from the IMAP server flags.
>> Right now, Gnus relies on its own read/unread marks, and will not query
>> the server for group flags unless you manually delete the "active"
>> parameter for a group, and force it to re-scan the group.
>
> If you're talking to a modern IMAP server, then Gnus will issue QRESYNC
> commands to the server and will get all new events that have happened.
> This includes read/unread marks and all the rest.
>
> If the server doesn't support that, there's not much that Gnus can do
> without agressively re-requesting all the data on the server, and that's
> going to be s-l-o-w.  So I don't think this is a bug.

This was almost certainly an early confusion on my part about how nnimap
works, thanks for closing.