[Dovecot] automatic flag updates

[Aaron VanDevender]

Timo,

(Sorry for the delay in replying. I had a...thing.)

On Wed, 2004-12-01 at 00:54 +0200, Timo Sirainen wrote:
> On 1.12.2004, at 00:30, Aaron VanDevender wrote:
> 
> > On Tue, 2004-11-30 at 09:00 +0200, Timo Sirainen wrote:
> >>> at this point I expect client A to change the status of the mail in
> >>> question to SEEN, but it stays as UNSEEN. The session below is from
> >>> client A. Command A00069 reports [UNSEEN 16265]
> >>
> >> That does seem to be bug.
> >
> > Do you mean an Evolution bug, or a Dovecot bug?
> 
> Dovecot bug.

Is this a dovecot bug that might be getting a fix anytime soon?

> > This race window is even wider for other folders. If the client spends
> > most of its time in INBOX, and only periodically SELECTs over to, say, 
> > a
> > Mailing-List folder, for a STATUS or a LIST check, then most likely if 
> > a
> > message in the Mailing-List folder is marked SEEN it won't be picked up
> > by the client at all, because it was NOOPing INBOX and SELECT doesn't
> > return FETCH FLAGS. The only way to avoid this is just to have SELECT
> > return FETCH FLAGS updates.
> 
> In theory that could work for a single session, but I don't think it's 
> such a good idea. It assumes that all clients want to know about all 
> changes all the time. This isn't true for example for Pine, 
> webmail+caching imap proxy, and other clients that just don't care and 
> fetch only what they want to know.

But pine doesn't constantly SELECT between folders either, and as long
as it dosen't do that, its not going to get flag updates for folders it
isn't interested in. I don't think that caching imap proxies are doing a
lot of automatic SELECTs either.

> And most of the clients that do want to know about all changes issue 
> FETCH 1:* FLAGS right after SELECT in any case, making Dovecot only 
> waste bandwidth with them. Evolution is about the only exception which 
> doesn't do this.

But isn't FETCH 1:* FLAGS the *real* bandwidth culprit? I mean which is
going to cost you more bandwidth: 1) requesting the flags of 10k
messages every minute continuously, or 2) simply being notified of
updated flags, and only updated flags, only when something changes?
Clearly 2 is going to use vastly less bandwidth. If we cater to style 2,
we might waste a tiny fraction of our bandwidth for some clients, but
evolution will save a bundle (and other clients might adopt that
strategy), and everyone's clients will work correctly. If we stick with
style 1, we save a bit of bandwidth on some people's clients and
Evolution's flags gets broken. The choice seems pretty clear to me. (And
didn't you admit that this was a bug in dovecot at the top of this
mail?)

> Also if the connection gets closed, there is no longer any way to 
> resend the flags because there's no way to identify one client from 
> another.

I think that any client which drops the connection and reopens it is
going to have to resync. Evolution already does this. But I don't see
what that has to do with SELECTing different folders.

> The real solution for this is CONDSTORE extension which allows fetching 
> only changed flags.

Yes, well I don't think that solution is going to get us out of any
holes anytime soon.

-- 

sig at netdot.net
Plead the First.