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


