Re: [Imap-protocol] QRESYNC & Long Command Lines
Michael M Slusarz <[email protected]>
| Newsgroups | gmane.mail.imap.general |
|---|---|
| Message-ID | <20130302210212.Horde.q66x7X5K6O_eEUdg-T5_zg1@bigworm.curecanti.org> |
Quoting Timo Sirainen <[email protected]>: > On 18.2.2013, at 9.24, Michael M Slusarz <[email protected]> wrote: > >> There seems to be a conflict between the recommendations in RFC >> 2683 [3.2.1.5] and the QRESYNC extension to the SELECT/EXAMINE >> command. >> >> A user recently reported an issue involving an overly long UID list >> passed to the FETCH command. Although not using caching >> themselves, while analyzing the issue I quickly realized that there >> could potentially be issues in passing a lengthy cached UID list to >> SELECT/EXAMINE. >> >> This particular user's mailbox contained 6-digit UIDs that were not >> sequential. In this hypothetical: >> >> - 1500 cached messages >> - non-sequential UIDs >> - All UIDs are 6 digits >> >> ...the UID string alone would be approximately 10500 characters >> (1500 UIDs * 6 characters + 1499 ',' characters). This doesn't >> factor in the rest of the command - or even the optional 4th >> sequence match parameter. Obviously, the 1000 character limit for >> outgoing client IMAP commands suggested in RFC 2683 has pretty much >> been obsoleted. > > I don't think the idea was to provide all the known UIDs. The first > UID range is about giving FLAGS replies only those ones listed. I > think it's basically always 1:<last UID you know of>. Or if you > happen to be doing something more special where you're caching only > a partial state of the mailbox, you could decide to create for > example max. 1000 bytes of UID string and then start merging the UID > ranges. You'll get a few bytes of more data but it shouldn't matter > that much. Our client NEVER caches the entire mailbox - only tiny view windows (100 messages/slice). I have a trash mailbox with 100,000+ messages. I am never going to load that entire mailbox into memory/cache. At best, I will open the mailbox (loading, say, 100 message in the slice), do a search to find what I need (loading up to another 100 unique messages), and maybe move around the search results a bit (possibly loading another 100-200 messages as I do a bit of scrolling). So I only have 400 messages in my cache. I most certainly do not want flag changes for the entire mailbox. But with the command size limitations I do have to make some compromises for long UID lists. So I picked an arbitrary sequence-set length which, when exceeded, we necessarily fall-back to a <first known UID>:<last known UID> range. I guess I could get fancier and try to optimize this more -- e.g. cut out UID "holes" over a certain length -- but seems like a waste of time since I've never actually heard of a SELECT/EXAMINE failing with our software due to a long UID string in the 4 years we have implemented QRESYNC. So this is more of a theoretical exercise than anything else. michael _______________________________________________ Imap-protocol mailing list [email protected] http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol