Webmail applications that are kind to the IMAP server?

[JP Howard]

On Tue, 3 Sep 2002 10:00:59 -0400 (EDT), "Rob Siemborski"
<rjs3 at andrew.cmu.edu> said:
> On Tue, 3 Sep 2002, JP Howard wrote:
>
> > Actually, a simpler answer is to just create a "socket pool".
> > Simply create a daemon that stores a socket for each user in a
> > hash/dictionary. The daemon listens for a request like "get
> > <username> <password>" and passes the socket from the pool
> > (creating one if necessary by logging in to the IMAP server). Then
> > the web app just uses the socket as per usual, and when done sends
> > an "unlock <username>" back to the daemon.
>
> I'm not convinced this is good enough, since a user could conceivably
> have two sepperate webmail sessions on the same system (imagine two
> windows open to the same webserver, browsing different mailboxes).
> Now which session knows the state of the IMAP connection?
>
> You need something to juggle the possibility that there are multiple
> concurrent web accesses for a given userid, and just storing a single
> socket in the selected state isn't good enough.
>
Yes, that's right. We're not currently optimising this, because we
don't store state in our pool yet (so we reselect mailboxes
redundently). Having said that, this is an optimisation that we'll be
adding and it really isn't a big problem...

Basically, each element in our hash/dictionary currently is an array of
open sockets for that user. There is also information about which are
locked (e.g. currently being used by the web app). So it handles
multiple processes per user, by creating a new socket if there are no
unlocked ones. We've found this approach works pretty well at the
moment. Sometimes a web app session my die unexpectedly and leave
sockets locked, so a cleanup process runs every now and again and
cleans up sessions locked for too long.

To handle tracking state (e.g. what folder is selected) when we do this
optimisation, we'll add this info into the hash. It will be returned
along with the socket. It will be up to the web app to utilise this
info appropriately--although we already abstract all IMAP comms through
a class, which makes that easier to automate.

Of course, it would be much easier if there was some way to find out
from Cyrus directly the current state of a process, since then it
wouldn't be necessary to track it in the socket pool. Rob has recently
asked about this in another thread, although I don't think anyone's
suggested any answers as yet.