Forum OpenACS Q&A: Re: The webmail problem

Collapse
7: Re: The webmail problem (response to 1)
Posted by Jonathan Ellis on 03/13/03 01:16 AM
I experimented with IMP a year ago or so, and either php sucks, aolserver's php support sucks, or imp sucks, because it was INCREDIBLY slow.  We're talking pages that do lots of ACS 4 permissioning without all the OACS optimizations slow. :P

Of course that could be past tense now but I was very underwhelmed.

Collapse
8: Re: The webmail problem (response to 7)
Posted by Rich Graves on 03/13/03 04:40 AM
I would not expect aolserver/php to be well tested, let alone optimized. Why would someone use php when tcl is right there?

IMP works well in our environment (http://web.brandeis.edu/pages/view/Network/EmailArchitecture).

IMP talking to UW IMAPd or any other server that needs to fork a new heavyweight process per connection can suck. IMP flaps a new process for EVERY OPERATION, which isn't really how IMAP is supposed to work. ImapProxy (http://www.horde.org/imapproxy/) is intended to address this, but I don't trust it yet. Large mbox-formatted mailboxes suck in general. With UW IMAP, read drivers.txt and use mbx format. Cyrus and Maildir have their fans, too. Exchange tends to do reasonably well because it's multithreaded.

Collapse
9: Re: The webmail problem (response to 8)
Posted by Vlad Seryakov on 03/13/03 04:11 PM
That's why ns_imap caches all connections to IMAP server, so
you do not open new imap connection with every HTTP request like it is done in almost all PHP Webmail products.
Once the IMAP session is created, it lasts as long as needed and
garbage collection thread closes unused sessions periodically. In this case acess to IMAP server is very fast, c-client IMAP caches all messages and so does IMAP server on the other end, so standard
mailbox format is not an issue here, once mailbox file is open and parsed, you do not need to scan directory and close/open new messages.