To me the main reason for doing it is performance and functionality.
Performance seems to dictate raw PHP directly against the database.
(I'm thinking c10k thaughts here ;->). I haven't looked in detail at the
db structure but from what I have seen so far its fairly simple, so
maintaining direct query's against mysql/postgres shouldn't be too evil.
For functionality you get to include all the sieve stuff "real easy
like" and password changing etc.
How many users do people have attached to what box and are there any
performance issues there?
End of response and start of general ramble
I'm not a C coder (just yet) but i have done a fair bit of programming
and database work and I'm looking to help, I am moving from windows to
Linux and liking it ;->. I like the email in database idea, I can see
it scaling a long way, (with a manager program) and providing good fault
tolerance for HA apps.
The other advantage to the stored procedure model is you can write
procedures and give the users access to them in the database directly
rather than going through IMAP if somebody wants to write an extension
then the mail client can bypass the IMAP handler totally.
<random>
I was wondering if it would be possible to have thunderbird use sqllite
or other DB as its mailstore rather than its current (and seemingly
dodgy) mbox support.
</random>
Some general thoughts on email + database.
I see it ending up such that each user has their own DB and that can be
replicated to/on other servers (managed by a manager program). So to add
capacity to your mail server get any old PC, stick mysql/postgres +
helper program on it and tell the manager program to use it. Manager
program talks to helper on the node and monitors its load, if its load
is below the average load for the rest of the servers then the manager
replicates a db over to it (starting with high load users) then tells
the smtp/imap front ends to use that new server. Each users database
should be kept on 2 servers minimum for redundancy. Manager program
keeps everything in synch and handles databases/nodes coming back from
offline mode.
With the right IMAP front end on it you should be able to get fault
tolerance in everything and hopefully pretty much linear scaling.
[EMAIL PROTECTED] wrote:
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
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
