MBOX-Line: From blong at google.com  Thu Nov 15 22:06:10 2012
To: imap-protocol@u.washington.edu
From: Brandon Long <blong@google.com>
Date: Fri Jun  8 12:34:49 2018
Subject: [Imap-protocol] Suspend/Restore feature proposal
In-Reply-To: <20121115215854.Horde.zz6B0O0tmt3ylHiEXzXhQQ4@bigworm.curecanti.org>
References: <20121115215854.Horde.zz6B0O0tmt3ylHiEXzXhQQ4@bigworm.curecanti.org>
Message-ID: <CABa8R6tHP2My0k2LqT1RzHoLQZA+X_jwUMU0cydm2sAwo8f4Fg@mail.gmail.com>

At the very least, I think you need to specify exactly what state is
maintained.

I also think ideas like a server which supports suspend can't issue
capability at login is non-starter.  Just because the server supports this
suspend, doesn't mean all the clients will, and it makes no sense to punish
the other clients for this.

Also, wouldn't something like the RECONNECT proposal from lemonade make
more sense, actually connecting to the exact state?

Can't we just pipeline all of this?

And frankly, the amount of state needed to transfer on reconnect for actual
folder state can be high (though, not as bad with CONDSTORE/QRESYNC).

Brandon


On Thu, Nov 15, 2012 at 8:58 PM, Michael M Slusarz <slusarz@curecanti.org>wrote:

> All,
>
> Moving this over from the Dovecot list, where this thread has been off/on (
> http://markmail.org/thread/**z7ctwle2go6zafas<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<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<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<http://dovecot.markmail.org/thread/qp45yod5ukqf3jfn>
> ).
>
> Comments/criticisms requested.
>
> michael
>
> ______________________________**_________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman2.u.washington.**edu/mailman/listinfo/imap-**protocol<http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20121115/621e1ab6/attachment.html>
