Date: 04 Mar 2003 19:34:46 +0200 From: Timo Sirainen <[EMAIL PROTECTED]> [...] Say I want to open one message in a mail client that first shows a list of messages:
1 FETCH 1:30 ENVELOPE (fetch a screenful) 2 FETCH 20 BODYSTRUCTURE 3 FETCH 20 BODY[1] Now why would you have needed to fetch the other 29 BODYSTRUCTUREs, except if you wanted to show a nice icon for message type? 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. Now, maybe if the message set under consideration is 1:50000 there's a different calculation to make, but for 30 messages it's easy. > Many servers cache BODYSTRUCTURE responses, so it is fast. Yes, some servers uselessly cache BODYSTRUCTURE in disk and lets them slow down processing other commands. If a client fetches BODYSTRUCTURE for a message just once, is it worth it to keep it lying around in disk, causing extra disk I/O? Even worse if client never asks for BODYSTRUCTURE, but the server has it stored just in case. 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. Well, depends on the server usage I guess. Should it try to optimize for fast replies to clients in usually idle server, or should it try to optimize the overall performance when disk I/O is being bottleneck almost all the time on a very busy server. Well, given that existing clients that want to present paperclip icons are going to fetch BODYSTRUCTURE, your server should probably optimize for that. (Heck, if you want to optimize for popular existing clients, you should also cache the entire RFC 822 header of the message, which again dwarfs the BODYSTRUCTURE.) Larry
