Re: [Imap-protocol] Detecting HIGHESTMODSEQ changes/polling for flag changes
Ian Anderson <[email protected]>
| Newsgroups | gmane.mail.imap.general |
|---|---|
| Message-ID | <[email protected]> |
That’s all well and good for Gmail (and thanks for making that change!), but they aren’t the only ones by far. (Although they are certainly a significant big one.) Does doing STATUS on a SELECTed connection would seem reasonable on first glance as a more general solution? Or is that just not done? Trying to wait out all of the perfectly-legal-but-somewhat-unfortunate servers seems like an exercise in futility… Ian On Mar 20, 2014, at 12:17 PM, Brandon Long <[email protected]> wrote: > Our support for unsolicited FETCH responses is in testing. Anyone who would like to test it is welcome to ping me, and I can enable it for the accounts you specify. > > Brandon > > > On Thu, Mar 20, 2014 at 12:07 PM, Jan Kundrát <[email protected]> wrote: > On Thursday, 20 March 2014 14:32:30 EDT, Ian Anderson wrote: > I’m finding it dismayingly common that servers don’t give flag changes (i.e. an untagged FETCH response with FLAGS) on a NOOP. Some of them don’t support IDLE, or don’t give flag changes on IDLE either. At least some of the servers do support CONDSTORE though. > > I'm willing to argue that these servers are broken, and yes, I'm well aware that GMail is among them, and yes, this is despite the fact that RFC2177 does not mention FLAGS explicitly. See [1] (and the rest of that thread) for details. > > Seriously, letting one know about new messages, deleted messages *and* changes of messages' status is the whole point of IDLE. Randomly picking just a subset of these events and not notifying on the rest of them means that we're back to polling. If we're polling, we could very well get rid of the whole IDLE in the first place. > > Anyway, Google's position on the issue is also documented in that thread, so there isn't much point in rehashing it again, I guess. The fact is that compared to the API which is available to their own client, the interface made available via IMAP is seriously limited. Take your own conclusions from that. > > Cheers, > Jan _______________________________________________ Imap-protocol mailing list [email protected] http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol