Stephen R. van den Berg answers me: > >I was thinking of the fsck operation to fix the mime headers and > >messages.rfc822.size. > > I see. Well, I specifically want to avoid this. If at all, this should/could > be an on-the-fly correction for just the mail at hand while/right-before it is > being retrieved.
Unfortunately, the most common case is something like a uid fetch 1234:5678 (bodystructure rfc822size) ie. retrieve total size, some header information and the mime structure for a set of messages.. Currently aox processes such commands without ever looking at the bodyparts table. I should like to keep that true. > >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. > > That would be fine. If a user can choose between not having access > to his mail at all, or access to those parts that are there, then > he'll usually pick option one. And I like it better than assuming that admins will diddle the right bits in the database. Database consistency is a fine thing. I should hate to have it rely on human procedure. > >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. > > I agree that the solution is not ideal, but extreme conditions require > compromise solutions. If you can come up with a better compromise > solution, I'm all ears. If my brain comes up with anything you may be sure that I shall tell all about it at the earliest opportunity. Arnt
