[Dovecot] automatic flag updates

[Timo Sirainen]

On Thu, 2005-03-24 at 14:57 -0600, Aaron VanDevender 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?

It should be fixed in 1.0-tests/stable. Most likely won't get fixed in
0.99.x..

> > > 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.

But when you actually change the folder in Pine, it starts fetching the
flags for the messages that are visible in screen. So depending on the
height of your terminal, something like 20-50.

> > 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?

Yes. But that's what most of the clients do. I can't change that.

> 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?)

No, just the UNSEEN sequence number was wrong.

> > 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.

So, you meant the flags would only be sent between SELECTs within same
session. Hmm. That might work. Only problem is that Dovecot would use up
more memory since it has to keep all the accessed mailboxes open. Not a
really good idea.

Also most of the clients wouldn't want to do that because Dovecot would
be the only server where it worked. So all in all, this would just
benefit Evolution users.

> > 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.

It's pretty much the only non-kludgy solution.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://dovecot.org/pipermail/dovecot/attachments/20050324/21daf2d3/attachment-0001.bin>