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

On Wed, Nov 28, 2012, at 12:04 AM, L Walsh 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?

Indeed this.  Our webmail runs in mod_perl2, so it's persistent, but there's
no guarantee that you'll get the same process on the next web hit.  We have
a thing called 'imappool', which is evil, but works very well.  Every
connection has associated state.  It actually passes the unix descriptor
backwards and forwards between processes.  It's super-fast.

We actually send a command 'XDUMMY' to the backend now, which just gets a
BAD response - but at least it confirms that the connection is still there
so that if a backend goes away we get all the same sort of failure rather
than random failures.

The plan is to replace XDUMMY with something that actually gets a new
SESSIONID from the backend.  We create a new SESSIONID every login and
it gets logged along with every change.  That way we can track changes
back to their source login - but tracking them to the exact web hit would
be even nicer.

Point is - it can be done.  I see that someone who wants to build a PHP
app which can be uploaded to j-random-webhost without having control over
the host configuration makes things hard though... no good answer there
except that IMAP isn't a great match for that configuration.

Bron.
-- 
  Bron Gondwana
  [email protected]

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