My two cents.
I would also concentrate on general optimization within IMAP rather than
another API. Reason being there this is no need to reinvent the wheel
when there are still much to be done to improve IMAP speed especially
when development resources are not exactly plentiful. I think there are
only 2-3 active developers and they are already more stuff to do than
man hours in my view: overworked.
Instead of stored procedures, using prepared statements for both
mysql/postgres I think will have a noticeable improvement.
In my own web app, I have a query abstraction layer which automatically
generate the proper prepared statement, only if another one has not been
previous created/cached, and execute bound parameters. This method would
help dbmail as it dbmail does not "kill" the mysql connection after each
IMAP connection thus prepared statement caching will help plenty as the
number of "repeating" queries dbmail issues is several magnitudes more
than most sql based apps. With prepared statements, at least with mysql,
binary protocol is used which is a bit faster since no encoding/decoding
is necessary and the second time the prepared statement is run, there is
no need for mysql server to parse the sql string. Dynamically generated
prepared statements is much more cross-db portable than stored procedures.
Xing
Casper Langemeijer wrote:
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
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
