At 12:43 AM -0700 9/27/01, Jonathan Lang wrote: > I've found that server mode, while nice, is quite lacking - my users, for >various reasons, tend to like to leave their email on the server for x days >- resulting in a couple messages being regularly deleted - but a large mail >spool. Startup is vastly improved, but shutdown can be quite slow. >Additionally, when the user receives mail, on the next POP access, qpopper >adds the X-UIDL header (if update-status-headers is disabled, and >server-mode is enabled, will qpopper keep track of the UIDLs in the cache >file, or will it need to regenerate them every time? The docs indicate this >will trigger it to re-read everything it needs to regenerate the header - >back to our original problem)
The UID is cached, along with status, index, and some other stuff. > > I came up with an idea to work around this, and was wondering if anyone >has coded a patch to do this: > > Completely seperate out any changes qpopper would make - instead of the >current (minimal) caching qpopper does, cache the X-UIDL, Message-ID, and >status of the message (along with the info needed to locate and verify >messages, of course) > > On startup, qpopper does some quick tests to verify that the spool has >only been appended to, and if so, reads in any additions, generates the >X-UIDL and Status header information, but upon exit, instead of modifying >the spool - it records this data to the cache file. Only qpopper will see >this, but ... that should be okay. > > Additionally, instead of deleting a message right away - this allows us to >mark a message as deleted, and then set a threshold (number of deleted >messages or size of deleted messages) and the actual purge will not be >accomplished until that threshold is reached. > > Benefit is that qpopper will ONLY need to scan new messages on startup >(ala current server mode) and on exit, will ONLY need to make a change *if* >a message is deleted (and, if enabled, the threshold is met) In all other >cases, qpopper will only update the cache file. > > This means startup and shutdown would both be very first for almost all >connections - not just the (rare) case where *no* new mail has arrived *and* >no old mail was deleted. Atleast in my experience - the only current >benefit for server mode is startup time. > > *IF* qpopper finds on startup that something has mucked with the spool >file - if dumps all but the status, x-uidl and message-id data from the >cache file, and scans the mailspool. Then, when scanning the spool, it uses >the message-id field to cross-reference existing entries in the cache - thus >enabling it to keep track of status/x-uidl, even if the spool has been >mucked with. It'd be 'safe' to use this *and* a standard mail client, >although you would lose some/much of the benefit. > > Anyways, original question - does anyone know of such a patch currently >available? This is well within my skills to code up, but not within my >availability. I figure, with this done right, the average user wouldn't be >able to tell the difference between this, and a true database for the >backend - while retaining full mbox compatability. There's a lot more that could be done, and yours is a good suggestion. The issue in implementing ideas such as this (and even the caching that was done for 4.0) is taking the time to be sure everything is done in a fail-safe way. Losing or corrupting data is the worst offense, in my book. --
