>Another option that comes to mind is a hybrid approach... I don't know >the guts of IMAP, but presumably it's plenty fast for a lot of >operations. The key then would be to provide a database API for the >operations it wasn't fast at. I suspect that could be substantially less >than 154 queries.
hm... and what interface should we use? I feel a non-standard IMAP extension coming up... It saves us the problem authenticating and the such. But what for? To have a custom webmail client that is faster than what we have now? The speed enhancements to be made in the mailclients itself far outweigh the improvement that can be made using non-standard extensions. webclients... I tried alot of them... roundcube, squirrelmail, dbwebmail. I use IlohaMail currently, because it's fast. It's *way* faster than the dbwebmail client. (I have >6000 mails in one mailbox, dbwebmail has serious O^n issues.) The best thing: All my users can use their own taste in client. The featurefreaks will use squirrelmail, designfreaks will use roundcube, speedfreaks use IlohaMail. They all use IMAP, and I'm very cool with that. Standards make it a no-brainer. I think that only if you want to build a mass mailhosting company you'll benefit from a direct connection to the db. Yes I like my users to be able to change their own passwords, manage mailfilter rules, create aliases and stuff. The interface for that is not there (except for managesieve), but hey, the application for that is not there yet too :-) Grtz, Casper
