Re: [Imap-protocol] Re: Suspend/Restore feature proposal

I believe he's dealing with an environment running php scripts with even
support as running as CGIs which are exec'd on every access.

Which isn't to say that some mechanism wouldn't be possible to do this
(fork a daemon that holds the connections and pass them to the new server
or something) but it gets complicated.

It would be much simpler to just have a long running server serve the
webpages directly instead of through CGI, but that's what he's got.

Brandon


On Tue, Nov 27, 2012 at 3:04 PM, L Walsh <[email protected]> wrote:

> 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
>
> ______________________________**_________________
> Imap-protocol mailing list
> [email protected]
> http://mailman2.u.washington.**edu/mailman/listinfo/imap-**protocol<http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol>
>

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