> And you never hereafter receive mail? The mbox -> database could be done both:
- From a cron job - Every time the user enters a POP3 session. > You need to at least have some interface for MTAs to deliver mail into > the database other than by someone popping their mail! That's other option, but the problem is to do a MDA for every MTA available, IMAP, and so on. With my approach you only need a mbox -> database transfer process that understand "mbox" and "MAILDIR" formats, for example. > I think you're really no longer talking about redesigning Qpopper > when you add this scope, you are talking about implementing most of a > complete new mail system, and you need to make it coexist with at > least the most common dozen or so other packages that form other parts > of the mail system. The implementing cost should be low, and current QPOPPER performance problems would banish. > see <http://www.dbmail.org/> I'll check it out. > If you're keeping initial messages delivered from [your MTA] in mbox > format, this probably means you're doing this mbox scan on many > sessions, which means you're doing a large part of the I/O currently > needed. When you copy "mbox" messages to the database, you delete the mbox. > This is the key advantage, but really this part boils down to having > a better message info cache system, which can be implemented without > completely reimplementing Qpopper into a database. Yeah. A possibility would be to keep certains headers (like "status" and "UIDL") in the cache file, INSTEAD the BIG mbox file. When you send a message to user, you insert the "cached" headers. So, you don't need to rewrite a entire mbox spool to rewrite a "Status: U" to "Status: RO". A paliative solution to current qpopper performance problems. > > - You can delete individual messages without needing a mailbox > > rewriting. > > You still have to rewrite the database... but you do save on > avoiding repeated handling of the old saved messages. (Maildir also > wins on this.) When you delete a message in the database, the write traffic is almost null. You mark blocks as "free" and almost nothing more. Nowhere near an entire spool rewrite. > Qpopper shouldn't be modifying the headers, other than to add a UID > (which can be avoided!) Qpopper rewrites "STATUS" header. Those modified headers should be kept in the cache file, not in the spool. > They require loading into the database at the next POP session, > though. Yeah. You aparentily triplicate disk activity: the email arrives and appends to mbox. The user POPs and POP daemon read the message and inserts it into the DB. But this cost is per message, and nothing comparing to an user with a 50 Mbytes spool file and "check email every minute" checked on :-). > That doesn't actually reduce I/O, just splits it up. Qpopper > doesn't read the whole 15MB in one chunk either. I know. I'm talking about memory issues, since many databases retrieve the entire register, eating tons of memory. Berkeley DB has not that problem. > Perhaps another way of putting it is: if all these changes were made > to Qpopper as you describe, would it still be Qpopper at the end and > usable as it is now, or would it be a totally different beast? Qpopper changes should be small; you change disk read/writes to database read/writes. Fairly drop-in. The mbox/maildir -> database translator should be least of 100 C language lines. The support utilities can be keep separated and the should be fairly simple also. > For Qpopper to be able to work as it does now, for systems using > just mbox format, but also be able to work as you describe, then its > present mailbox I/O would need to be abstracted to a separate mailbox > interface I/O layer This should be way. Right!. > All IMHO. As your sig says "Things are not so easy." Life is hard and we keep doing things in the hard way :-) -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ [EMAIL PROTECTED] http://www.argo.es/~jcea/ _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ _/_/_/_/_/ PGP Key Available at KeyServ _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
