21

Detach attachment(s) from email messages by (thus becoming 'detachments'):
a) saving it(them) into a chosen(or default) directory; then
b) removing/deleting it from the email, while retaining the rest of the email
contents; and
c) putting a linking phrase/identifier into the email with possible tagging data such as date, size, type; so detached attachment is openable from within email by a link (or even inline viewing still intact).

d) Optionally: upon forwarding email, 'detachments' will be RE-attached before sending (further option[preference]: if detached, then saved sent forwarded email message will only retain 'detachment link'.

I have been itching for this feature set for a long time. There exists a pipe through filter 'Kmail Power Tools' written in perl listed on kde-apps.org, but a built solution would be preferable - thus giving (d) above.

I greatly enjoy using KMail, as it has been a very solid and often used app.

Someone should probably confirm this, but I don't think attachments are actually downloaded unless you ask them to. So removing the attachment from the email would be redundant, since it isn't actually in the email to begin with.

@TheBlackCat: Are you thinking IMAP?
I personally use KMail for mostly POP accounts, and all the emails are downloaded (POP filtering aside, spam, etc) attachments included. Then on most business related emails that have docs attached, I will save to a directory (for mine and others consumption). This detachment idea would offload my email storage (from GB's down to MB's), but still give me quick access to the attached doc/file if I forward or look for the doc from within KMail.

To Note: My ultimate dream would be, to Not have to be concerned with filing any docs/files into the FS but the detaching would be done automagically (filters, tags, whatnot...). And finding the doc would be a matter of semantic/contextual requests (desktop search on roids =).

I approved it, as I have same "problem" wish for KMail.
I think it's good idea and it should be discussed.

This is probably something which will be implemented once developer resources become available again when the Akonadi port is finished.

Fun fact: the Akonadi application tutorial uses this kind of feature to demonstrate Akonadi data manipulation:
http://techbase.kde.org/Development/Tut ... pplication

Why do you need "Akonadi" to simply manage mail attachements ?
Thunderbird is managing attachments for years, without any extra special tools or services.

I do not use and do not need Akonadi (installed because forced to, but disabled).
Why forcing Akonadi service activated to make a simple detachment operation ?
Make is simple !

Kmail will use akonadi for everything. You won't be able to use kmail without using akonadi starting, probably, with KDE 4.5. Kmail will work largely as before, it will simply be using akonadi as its backend.

"Kmail will use akonadi for everything"

The question is why using more and more complex things, potentially less and less reliable to make simple things ?
This question should be raised before thinking of KDE 4.5 !
Starting Akonadi service for Kmail does not seem to be a clever choice to simply manage attachments. (Thunderbird should be investigated to not reinvent the wheel).

The reason is because akonadi lets you do a lot of things you couldn't do before, and provides a lot more flexibility.

I am not sure Kmail users really want to "do a lot of things" for the moment, but at least what Thunderbird is able to do without any Akonadi or equivalent, for example:
- detaching attachments;
- easily check/edit the formatted HTML code before sending etc etc.
Not sure waiting for KDE4.5 with Akonadi to make such basic things is perceived as a great evolution from user point of view.
Thunderbird will still be there as a backup in case the increasing complexity is not fitting user needs.
(I make the parallel with Amarok 1.4 which became Amarok 2 / this is another story about increasing complexity not so warmly welcome, to not say it differently).
Simplicity and reliability are also requested by a certain category of users.
Hope KDE4 will not progressively loose such category of users.

L_V wrote:Why do you need "Akonadi" to simply manage mail attachements ?
Thunderbird is managing attachments for years, without any extra special tools or services.

I think you don't realy understand what akonadi does. It is not intended to manage mail attachements, that is just an example of some bonus features. The main objective is data storage for all PIM (personal information manager) applications.

more info:
http://pim.kde.org/akonadi/

http://pim.kde.org/home.php/

Da Sheep

I use ics calendars for years, and don't need Akonadi at all (disabled, and installed because forced to).
ics calendars have the great advantage to be sharable with mozilla applications and others, then more generic.
I don't see any added value by putting my calendars in Akonadi running in background.
For my personal use, Akonadi would be used only by detaching feature of Kmail.
May be Akonadi is better fitted to big networks with many users on one server.
I only use KDE on a personal desktop, and try to avoid unnecessary complexity and bugs, and CPU/memory consumption.
This was just a personal feedback made by a desktop user looking for simplicity and reliability.

You still don't understand. Currently akonadi is only used to a limited extent in KDE PIM applications. But over the next two releases all PIM applications will be converted to use Akonadi for everything. You will not be able to pick and choose what you use Akonadi for. Kmail will simply be a front-end for akonadi, it will have no mail handling capability of its own. Korganizer will simply be a front-end for akonadi, it will not have the ability to look at calendars without it.

Akonadi will not be some new format for storing data, it will use standard formats and protocols like ics and imap (if you look at the calendar formats, it already supports ics files). What it will provide is three main things. First, it will provide a unified way for applications to access these resources. For instance your calendar application doesn't have to know whether it is looking at a local ICS file, an online google calendar, or an exchange server calendar. That makes it much easier to add new backends, and there are already far more backends for akonadi then there ever were for the old KDE PIM applications. Second, it provides a way for multiple applications to access the same data simultaneously without adding much extra overhead or additional configuration. For instance your plasma calendar widget, your korganizer calendar, and your cell phone sync software all get data from the same place, they just provide a different GUI for it. Third, it allows for different PIM data to be integrated more closely. So for instance your PIM applications will all recognize that your boss mentioned in a meeting in your calendar, mentioned in emails, mentioned in chat logs, and mentioned in notes are all the same person, allowing you to get data related to him or her easily.

Once done it will add a great deal of simplicity and reliability. There will be no need to set up your email client or your calendar individually for each of your applications. There will be no need to keep a separate address book for all your email and chat programs. There will be no need to install separate programs just to get support for obscure protocols.

The subject is: Detach attachments (save, remove, and link) from email

Then, no, I am still not convinced at all that Akonadi is necessary to make such basic feature.
Akonadi should be used only for things which cannot be done differently, or where a real added value is identified, and not used because Akonadi is there.
Once more, this is not a developer view more motivated by developing things in different and new ways, more than reusing what it already known and solid from others, but a pragmatic view from a Desktop user who wants to be sure that if KDEpim becomes too complex (to not say bloated), and more complex than necessary, moving back to mozilla applications can be made without special efforts.

Well you can think whatever you want about what akonadi should be used for, I am telling you what it will be used for: everything.