On Tue, 2003-03-04 at 20:04, Lawrence Greenfield wrote: > This would be stupid for any client to do. > > 1 FETCH 1:30 (ENVELOPE BODYSTRUCTURE) > 2 FETCH 20 BODY[1] > > is considerably more efficient. Either the user asks for other > messages or they don't; you're no worse off since the extra data > you're transferring is drowned in the RTT.
BODYSTRUCTURE isn't immediately needed while showing the message list. But sure, if user immediately opens one message it could have helped a bit if BODYSTRUCTURE was already known. > BODYSTRUCTURE doesn't occupy that much more disk space. If you're > already caching ENVELOPE data there seems to be little reason to avoid > caching BODYSTRUCTURE data. If you don't need BODYSTRUCTURE data, it's just extra disk I/O every time you have to jump over it. > Well, given that existing clients that want to present paperclip icons > are going to fetch BODYSTRUCTURE, your server should probably optimize > for that. Outlook and OE for example don't want BODY, BODYSTRUCTURE or ENVELOPE. Caching any of them for these clients is just waste of disk space and disk I/O. Currently my server starts caching those fields the first time after they've been asked (per-mailbox). That probably works quite well as long as people don't switch to different client. I've also been thinking about collecting some I/O statistics, assuming that itself won't need extra I/O. So that every time some cached field is needed, server counts how many bytes we saved because we didn't have to open and parse through the message. And every time we have to skip through cached field it would be decreased by that amount of bytes. Field would be cached or dropped from cache once the byte counts are too large or too small. Well, that's still in idea stage and probably has some problems, like that we shouldn't really count bytes that are already in OS's file cache.
