I think Paul was talking about between dbmail processes on multiple machines. Eg. You have 2 physical machines providing imap to a shared database backend. I don't know anything at all about memcached, but I'm guessing it's only for processes on a single system, so may have some benefits for specific installations, but can't be the solution to the problem as many sites have multiple dbmail servers running (you'd have to track changes in the database itsself, or come up with some other plan).
Perhaps combining the two approaches could work? Eg. you track changes in the database so all dbmail client machines can know about them, and create a specific thread/process on each dbmail machine that polls for changes and notifies the actual imap server threads/processes via memcached. On Thu, 2007-02-01 at 23:55 +1100, Jake Anderson wrote: > Should there be that much need for IPC? > unless you have shared inboxes why do multiple threads need to deal > with the same data?, I assume that transfers from a DB backend to an > IMAP front would be by shared memory and some sort of notify event? -- Jesse Norell - [EMAIL PROTECTED] Kentec Communications, Inc. _______________________________________________ Dbmail-dev mailing list [email protected] http://twister.fastxs.net/mailman/listinfo/dbmail-dev
