96 lines
4.7 KiB
Plaintext
96 lines
4.7 KiB
Plaintext
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>
|