On Tue, 2003-03-04 at 19:32, Lyndon Nerenberg wrote: > >Right, but the server can determine if the message definitely does not > >have an attachment, and most messages don't. Then there's no need to > >fetch bodystructure for just that information. > > This is a micro-optimization that provides little to no benefit.
Perhaps. > The > only time you can avoid issuing a bodystructure request is if all the > messages in the current view are flagged as having no attachments. The > chances of this being the case are very low. Once you have to issue a > bodystructure request, the additional overhead of asking for the > bodystructure for all messages in the view (versus fetching it for just > a few messages) in minimal. As Steve has already mentioned, your > overhead is in the RTTs, and not in the bandwidth for the bodystructure > response. And since you know you need the bodystructure anyway, you can > just combine it with the envelope fetch and save yourself the additional > RTT. I don't need the bodystructure "anyway", unless I intend to read all the messages. I could just fetch (FLAGS ENVELOPE) for visible messages, after that I would fetch BODYSTRUCTURE for messages that weren't marked with \NoAttachment flag to find out if I want to add some pretty icon to them. This could even be done on background without having to wait for it to finish, so RTT doesn't really matter. You'd likely also get the messages into screen faster (except for those icons). > And I still claim that the server cannot correctly decide what > constitutes an "attachment" in the clients context. For example, > does the following message get a \attachment flag? Yes, I agree that server doesn't always know that. I never said it would have to know. What servers can know is if message _definitely_ has attachments, or if message _definitely does not_ have attachments. If it doesn't know, it wouldn't return anything and client would fallback to FETCH BODYSTRUCTURE to figure it out by itself. Most of my messages are still text/plain, so client wouldn't need to do that very often. > What you are really flagging is that the message is a multipart, and not > that it has "attachments." We already have a mechanism to determine if > a message contains multiple parts: fetch bodystructure. Which has unneededly large overhead for such a simple task as this.
