On Wednesday, October 05, 2005, at 03:31 PM, Paul Van Noord wrote: DAC>> To me, using the attachment is what one is doing if one is attempting DAC>> to forward it. TB! should assume that the user wants it to do what the DAC>> user tells it to do. If the user is not interested in the attachment, DAC>> why should TB! know to go back and download it then forward it.
> I agree!
IMO, the following should happen:
Hit forward and TB! popups up this message:
The attachment/s associated with this message have not yet been
retrieved from the server. Do you wish to retrieve and send the
attachment/s as well.
[Yes] [No]
[ ] Make my choice the default.
(There should be an option in the preferences so that you can adjust
the default behaviour, i.e., prompt all the time or yes/no all the
time.)
Yes - will make TB! retrieve the attachments.
No - will make TB! generate the message with null attachments. Those
not wanting null attachments can delete them. Those wanting null
attachments will leave them alone. This part, I could do without, but
you, Paul, mentioned that the null attachments would be useful to you.
:)
I strongly believe the option should be there. Why? I may wish to
forward the message without the attachments. Why should I then have to
download the attachments which may be huge, take up my bandwidth doing
all of that, only to delete them, as has been suggested?
Good IMAP is about efficiency. In fact, a fabulous IMAP client will
allow you to forward only some of the attachments if there are
multiple attachments. It will then retrieve only those attachments you
need to include in your forwarded message copy. I'm just not sure how
I'd elegantly go about it.
Perhaps this could be done:
After hitting yes, that you wish to retrieve the attachment/s, another
pop-up appears for those messages containing multiple attachments. The
pop-up will list the attachments that you may then use to select those
attachments you wish to send and hence retrieve.
It's not all the time that the user has enough bandwidth to just
retrieve attachments ad lib. I'm one such user and I know I'm not
alone, hence my appreciation for them. It's this sort of thing that I
miss about Mulberry. However, TB!'s current behaviour is *just*
adequate. I avoid certain messages at work because of this.
--
-= Curtis=-
Using TB! v3.61.07 Echo (Beta)
System Specs: http://specs.aimlink.name
=-=-=
...Oxymoron: Rising Deficits.
pgpI89csJY4lR.pgp
Description: PGP signature
________________________________________________________ Current beta is 3.61.09 (Echo) | 'Using TBBETA' information: http://www.silverstones.com/thebat/TBUDLInfo.html IMPORTANT: To register as a Beta tester, use this link first - http://www.ritlabs.com/en/partners/testers/
