>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. 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.
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?
multipart/mixed
text/plain
image/png; content-disposition=inline
The server should say "no," but the client on my PDA would disagree. In
the context of *my* client, that image/png is treated as an
attachment. The server-calculated \noattachment flag in incorrect.
Another example:
multipart/mixed
text/plain
text/plain
Does that second text/plain get flagged as an attachment? How about the
first one? The server cannot make this sort of decision. Only the
client has the context necessary to make those decisions.
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.
--lyndon
