On Thu, 2005-03-31 at 09:19 +0200, Paul J Stevens wrote: > > Wolfram A. Kraushaar wrote: > >>>Is it handled through database triggers. > >>>If not, what is the meachnism used to inform the clients > >> > >>about a new > >> > >>>message, deleted message or message state chage. > >> > >>DBMail doesn't support IDLE [yet?] > > > > > > dbmail-imapd would need an IPC/RPC interface to support IDLE > > which is then called by dbmail-smtpd/dbmail-lmtpd upon insertion > > because afair MySQL doesn't offer sth. like pg_notify. > > > > The other idea would be a "master" (like in Postfix) - but > > IDLE wouldn't work if you're running dbmail-l/smtpd and > > dbmail-imapd on different machines. > > That was my first idea as well: we need ipc, which will be hairy on > distributed > setups. But there's an easier way more in line with dbmail's basic design: > > All we need is a timestamp field on the mailbox which is automatically > updated > for each modification on a mailbox. Per mailbox-quota/usage updates would be > a > good reason for such updates with a nice spinoff: full mailbox quota support. > > In the client-handling process set a special SIGALRM during IDLE which will > probe for modification of the timestamp and if so, run a resync of the > mailbox > and sent notification of any changes to the IDLE clients.
Be careful doing non-atomic things during signals. Since the signal will likely have to write to a fifo anyway, it may be better to simply select () on that fifo in the first-place... -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
