53 lines
2.4 KiB
Plaintext
53 lines
2.4 KiB
Plaintext
MBOX-Line: From imap at tlinx.org Tue Nov 27 15:04:36 2012
|
|
To: imap-protocol@u.washington.edu
|
|
From: L Walsh <imap@tlinx.org>
|
|
Date: Fri Jun 8 12:34:49 2018
|
|
Subject: [Imap-protocol] Re: Suspend/Restore feature proposal
|
|
In-Reply-To: <20121115215854.Horde.zz6B0O0tmt3ylHiEXzXhQQ4@bigworm.curecanti.org>
|
|
References: <20121115215854.Horde.zz6B0O0tmt3ylHiEXzXhQQ4@bigworm.curecanti.org>
|
|
Message-ID: <50B54704.9020805@tlinx.org>
|
|
|
|
Michael M Slusarz wrote:
|
|
>
|
|
> Background: I am a disconnected client author (webmail).... I was
|
|
> depressed/alarmed at the amount of state re-creation ...need..
|
|
> 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.
|
|
---
|
|
Just ignore me if I'm too clueless for this to be of any help, but if I was
|
|
doing what you are doing, I'd cache the client TCP connections to the IMAP
|
|
server until I timed their session-out from my webserver.
|
|
|
|
I.e. would set cookie upon connection to their imap server that contains
|
|
a 'handle' that would indicate something in my 'IMAP-TCP connection cache',
|
|
and route their requests accordingly.
|
|
|
|
Not only are starting TCP connections "expensive", but you have an added
|
|
expense
|
|
of IMAP state... if HTTP(S), believes in using PIPELINING to enable lower
|
|
server loads and faster response time, why not a webmail->imap gateway?
|
|
|
|
Set the "session-timeout to ~5-15 minutes" of inactivity like many things
|
|
do and you can recycle their imap connection, but if they reconnect w/the
|
|
same cookie, it seems you could simply route their commands to the already
|
|
open connection to their imap server -- and there would be no overhead
|
|
of looking for capabilities, or resetting state...etc, as the TCP conn.
|
|
would guarantee it's the same server.
|
|
|
|
It would all be transparent to the user -- if they reconnect to you, you
|
|
look in your cache, and see if the TCP connection is still valid (or if it,
|
|
possibly, has been closed from the other end). If it has been, the safest
|
|
thing to do would be to give a message that the remote IMAP connection
|
|
timed-out and they need to re-connect.
|
|
|
|
Sorry, if this sounds too clueless for words, and I am missing something
|
|
obvious about why this can't be done -- but it sounds like rolling your
|
|
own connection cache would be the way to go...(but probably am missing
|
|
the forest for the trees....)...
|
|
|
|
-l
|
|
|
|
|