Re: Returning to ticks on read-only imap servers

[Michael Welsh Duggan <md5i@md5i.com>]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Michael Welsh Duggan <md5i@md5i.com> writes:
>
>> I'd like to revisit the issue of ticks on read-only nnimap servers.
>
> I think the last time I looked at this, I stopped when I found out that
> EXAMINE doesn't return enough data to say whether a group is read-only
> or not.  So nnimap has to issue a SELECT (which is slow) and then
> possibly store the information somewhere for later.  Perhaps the first
> time it sees the group?

I'm going to brainstorm here, so apologies if this seems a little
rambling.

Hmm...  When does the information about marks need to be known?  In
order to set a mark, you need to first enter the group, which
necessitates a select.  So, when it comes to setting marks, I think that
the information is on hand is available.  (EXAMINE probably doesn't give
you the right information because when EXAMINE is in play, the group is
read-only by definition.)  As for knowing about existing marks
beforehand...  If the group is not read-only, this already works.  If it
is read-only, the marks are stored on the client (in the .newsrc.eld).
Based on the fact that ticks that were set before nnimap was rewritten
still exist and work, it would seem that client-side marks are heeded
despite the fact that they do not exist on the server.  Unless this is
only the case because these marked articles are not in the last 100...

(BTW, that 100 should be in a variable, instead of being a constant
value.  I can see wanting to possibly change that number, possibly even
on a per-group basis.)

-- 
Michael Welsh Duggan
(md5i@md5i.com)