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

Quoting Brandon Long <[email protected]>:

> 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.

Yeah: this is exactly what imapproxy provides  
(http://www.imapproxy.org/).  Way back at the beginning of the thread  
I laid out the reason why this solution is insufficient or, at least,  
undesirable.

> 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.

Agreed.  If I was in charge of creating a closed system webmail  
architecture, this would be an obvious decision. (Mail store  
interaction would probably not be done via pure IMAP either).  But  
stock HTTP and IMAP servers is what most admins have to work with, so  
we desire to distribute a software solution to these people to ensure  
the largest possible audience.

> On Tue, Nov 27, 2012 at 3:04 PM, L Walsh <[email protected]> wrote:
>
>> 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?

At least one author of an IMAP server has stated that the TCP  
connection is no longer expensive and is, in fact, negligible when  
compared to running even a single IMAP command.

>> 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.

Yup - you've pretty much (re-)invented imapproxy.

michael

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