Re: can back end keep track of *all* group info?

[Simon Josefsson <jas@extundo.com>]

Paul Grayson <pgrayson+ding@ks.uiuc.edu> writes:

> My server keeps track of marks, and could report the number of
> unread/flagged messages in each group for display in the *Group*
> buffer.  I don't want my server to count the total number of messages
> in a group - that will take too long - and I want to avoid the nnimap
> problem of always having the unread/flagged count out of sync with the
> server.

Which problem is this?  Do you mean the one that unread/flagged count
in Gnus is only an estimate?  That applies to all backends, if it is
noticable or not depends on the backend (and in nnimap's case, on the
remote server).

M-g on the group makes Gnus update the estimate with real information
though.

Making the Group buffer use the real values from the backend, when
they are able to provide that data, should fix this problem and be
very useful.  Shouldn't be too difficult to do, I think.

> I love everything Gnus does, and really want to use it as a front end
> to this server - is there any way to write it a back end?  I've
> experimented a little, and it seems that Gnus generally requests much
> more information than it uses, but checks too rarely (with, for
> example, nnchoke-request-update-info) to keep the information
> up-to-date.  Is there any way to trick Gnus into letting the server
> keep track of everything, or would it mean rewriting a significant
> part of the front end?  Are there any plans for allowing this in the
> future?
>
> If I don't want to rewrite parts of Gnus, is it possible to write my
> own group-browsing mode and connect it to the Gnus summary mode?

If you implement `gnus-request-set-mark' your backend should at least
receive all flags as set by Gnus.  The other way is handled via
`nnchoke-request-update-info', but I'd agree that this is called too
many times and still not enough times. (This is way nnimap doesn't
have a `nnimap-request-update-info' but rather calls this function
internally upon group entry, in `nnimap-request-group' -- which
doesn't seem to cause any problems.)

> If you think this is not worth the work, is there any other email
> back end that lets you instantly re-split tens of thousands of
> messages?

You could have a look at Wanderlust, maybe their backend interface is
cleaner.