[Imap-protocol] Suspend/Restore feature proposal

All,

Moving this over from the Dovecot list, where this thread has been  
off/on (http://markmail.org/thread/z7ctwle2go6zafas).

Background: I am a disconnected client author (webmail).  Several  
years ago, I was in the process of adding extensions like QRESYNC and  
LANGUAGE to the code.  Staring at IMAP data over the course of several  
months, I was depressed/alarmed at the amount of state re-creation  
that needed to be done every time we connected to the server which,  
for a non-persistent webmail backend, was pretty much for every  
action.  We needed to do a NAMESPACE, CAPABILITY, (since there was no  
guarantee that we are connecting to the same backend IMAP server, it  
was/is not possible to cache these values on the client side), ENABLE  
QRESYNC, and LANGUAGE call on every user action.

imapproxy (http://imapproxy.org/) has been around for awhile and  
helped with the overhead dealing with establishing the connection  
between web backend and IMAP server.  However, what would be useful is  
that if we could somehow be guaranteed that the imapproxy connection  
was restored, rather than being newly created, then we could avoid  
having to send all the initialization commands and could reliably  
cache the NAMESPACE and CAPABILITY information.  So I went and hacked  
in the XIMAPPROXY code to imapproxy (see, e.g.,  
http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/trunk/imap_proxy/README?revision=14250), performance increases were significant, and life was  
ok.

But this is far from an ideal solution.  Some drawbacks:
   - You are limited to a 1 -> 1 backend to imapproxy server mapping,  
since there is no way to track which connection is being reused
   - It requires a separate service to be maintained.
   - It is specific to this proxy server.

Earlier this year, Timo mentioned that (paraphrasing) imapproxy was  
worthless since Dovecot was plenty fast in creating network  
connections.  While this eliminated one of the benefits of using an  
imap proxy it doesn't eliminate the state-restoring optimizations it  
hackishly provides.  Discussion ensued.  It was eventually determined  
that some sort of standardized state storage method would be a useful  
IMAP addition with the suggestion that maybe a more formalized draft  
would be useful to provoke yet more discussion.

I finally got off my rear and did just that.  Below find a  
proof-of-concept draft of a proposed SUSPEND extension, complete with  
example use cases:

https://raw.github.com/slusarz/horde-sandbox/master/imap-suspend-draft/draft-imap-suspend-00.txt

A rough Dovecot server implementation for this kind of feature has  
already been created  
(http://dovecot.markmail.org/thread/qp45yod5ukqf3jfn).

Comments/criticisms requested.

michael

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol