[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: auto-encrypt attachments: want to implement
From:       Ingo =?iso-8859-1?q?Kl=F6cker?= <ingo.kloecker () epost ! de>
Date:       2001-08-15 22:55:52
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mittwoch, 15. August 2001 12:07, Michael Häckel wrote:
> Removing attachments from the mails is not good, because information
> is lost by doing that.

If you do it the right way no information will be lost by doing that. 
For example we could keep the whole message as it is except that the 
body of the attachment body part is removed/replaced by a link (?). To 
restore the original message the saved body can simply be re-inserted.

> And if we can keep the attachments of incoming
> mails together with the mail, then we can that also for outgoing
> mails.
>
> Anyway a solution has already been discussed some time ago on this
> list, let's see, what Marc's new message class will bring.

Yeah, let's see. But nevertheless I have to say that for better 
performance (memory and cpu time) delayed attaching of (big) 
attachments is the way to go. Why should big attachments be included in 
the message before it's really necessary, i.e. before the message is 
actually sent or put in the outbox?
To avoid loosing attachments (because the user deletes the attached 
file after attaching it) they should of course be copied to KMail's 
tempdir. This will cost some hard disk space but IMHO saving memory is 
much more important than saving a little bit space on the hard disk.

Regards,
Ingo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7ev34GnR+RTDgudgRAqLWAJ4nXSnGb/ELujJj6pk0ywjtY/cL7ACgxxQF
GhA2VwY3v3oihCMbEcH20Iw=
=21SL
-----END PGP SIGNATURE-----
_______________________________________________
Kmail Developers mailing list
Kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail

[prev in list] [next in list] [prev in thread] [next in thread]