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@netdot.net Plead the First.