On 22.6.2012, at 0.58, Michael M Slusarz wrote: >> I think the conclusion is that imapproxy is not necessary. There are some >> advantages (eg with high network latency between web and imap server, and >> reducing apparent login count), and some disadvantages (extra complexity, >> slowdown) > > Not entirely true. See this thread: > > http://markmail.org/thread/z7ctwle2go6zafas > > Thread in short: imapproxy provides benefits for more MUAs that take > advantage of the XIMAPPROXY feature (only IMP, AFAIK), and Timo is/was > considering adding a similar state saving feature to Dovecot 2.2.
Well, I had completely forgotten about it :) Reading my old mail: > There isn't a whole lot of state to be saved really. Mailbox GUID, > UIDVALIDITY, > HIGHESTMODSEQ gives the mailbox state. Then you have the language/etc. states. > Clients could restore their earlier state from days ago, as long as Dovecot > still has the necessary .log records available (similar to how QRESYNC works). Yeah .. Perhaps something like: 1. if client issues LOGOUT XSTATE 2. And server sees that it can actually save all of the state (some things are a bit tricky, and probably not worth the trouble in initial implementation) 3. Then the server server sends * OK XSTATE <string> * BYE 4. The client can pipeline after LOGIN/AUTHENTICATE: a XSTATERESTORE <string> a OK Yeah! or a NO Not gonna work. Perhaps even a real RFC for this thing? .. If it's worth it.. Would save at least a few X bytes from network traffic :)
