Yes you're right, it was a completely personal flight of fancy, that
wouldn't apply to the general community. It would tear out some of the
great practicality of dbmail. You guys have convinced me that it's not
something I want to do right now anyway.
I'm going to start with creating a headers table to play with, I'll
submit some patches to the dev list if I come up with anything useful.
Eelco van Beek - IC&S wrote:
This is really like going back to basic.
DBmail's data model is not perfect the way it is right now. At
insertion time the data should be stored structured, this would make
any daemon for mail retrieval and storage faster than any filesystem
solution. We're not there yet since this will need quite a big code
change. Speed isn't the only big issue that DBmail is trying to solve.
Manageability, scalability and security are at least as important.
We have a site running dbmail with about 30.000 accounts and 12 Gbyte
of maildata. It's running smooth and there are never any complaints
from customers. We're also setting up a freemail site which uses
dbmail as its engine. For us this is the only way to really test
dbmail in high performance area's.
Speed hasn't been an issue for us since 1.0rc3 :)
Why do you want to store on the fs? (with all security and locking
problems involved?)
I think I like to make things harder than they actually are ;-)
Best regards,
Eelco
