On Thu, Nov 21, 2013 at 05:15:16PM +0100, Stephen R. van den Berg wrote: > Why should we be modifying the database?
I was thinking of the fsck operation to fix the mime headers and messages.rfc822.size. > What I would like to propose and implement is non-destructive on the db, > i.e. the db should not and must not be modified depending on the > (un)availability of the external bodyparts. > > There should be at most three settings to the system (possibly configurable > per mailfolder/user/globally): > a. Do not allow the folder to be opened unless all (external) bodyparts are > present and accounted for. > b. Do not allow the mail to be opened unless all (external) bodyparts are > available. > c. Allow the mail to be opened, even if external bodyparts are not available, > just include empty files (or placeholder space-garbage, whatever is > easier to implement) for the missing external bodyparts. > > I fail to understand how this could be hard on the database. In a and b, opening the mailbox always/generally (a/b) requires looking at all the bodyparts rows for all of the messages. That's is a considerable new load. For gmail-like mailboxes I think it's lethal. I'm uncertain about case c. If it's acceptable to pretend that the attachment is there until the very moment it's retrieved, then I think that can be done without significant cost. Some IMAP clients have a bothersome habit of retrying commands immediately if the first result wasn't to their liking. But aox already has code to deal with those, which should be easily adapted to this. So maybe I'm not firmly opposed to c. I do dislike it. The easiest way to implement it would be: - bodyparts grows a third field next to text and data - BodypartFetcher learnts to retrieve that field - the badcommand handler grows a new extra - The aox command grows a new subcommand to shift things out of the db Doing more is possible/sensible. I think I'm not firmly opposed to this. Would accept a patch. Arnt
