[Kde-pim] kio-slave for (email) attachments and other file-like items stored in Akonadi

Friedrich W. H. Kossebau kossebau at kde.org
Thu Apr 28 22:30:45 BST 2011


Hi,

doesn't this annoy you as well? You boot your KDE session and Okular greets 
you with that it cannot reopen the PDF file you have been sent the other day 
and have started to work on, and once you found the email with the PDF again 
and opened it, you see that all the bookmarks/comments you created in some 
hours are lost because Okular cannot map the (random) url to the very same 
document. Bah.
At least the Okular greeting happened to me yesterday again, and so I 
remembered what I proposed to Tobias König (Hei :) ) at the begin of this year 
and just added it in time to the soft feature freeze to the 4.7 feature plan, 
because I want to get it done finally: 

a kio-slave to access email attachments and other file-like items stored in 
Akonadi.

Current situation (not sure this holds with KMail2, please correct me):
Attachments in KMail (and else? where?) which are to be shown/opened with 
another program are written to a file in the real filesystem, somewhere in 
/tmp, with the "real" filename as given for the attachment + some random 
string + mimetype file extension.
But:
* File is deleted once another email is viewed, too bad if the program is 
still starting for that attachment in the email before (think OOo), it will no 
longer find the file passed as argument
* path/name of the file is different each time, bad for programs which store 
own data per file by the full path of that file (e.g. Okular)
* temporary file also bad with regard to "Recently opened" list and session-
management (example given above)
* "Save as" on attachment opened in external program does not have the 
original file name as default in the file dialog, instead that filled with 
that random (crap) chars which always have to be manually removed first to get 
a sane name.

I guess this could be solved with a kio-slave which can deliver the real data 
of an attachment by a constant unique identifying url from Akonadi.

Tobias told me to have a look at the akonadi:/ kio-slave which I did and also 
started with some code those days (but lost it meanwhile). IIRC I stopped 
because I was not sure if such a feature should be added to the existing 
akonadi kio-slave or to a separate one. I also was wondering about all the 
copying going on and if that could not be done more efficiently (like in a 
best case getting an offset to a file from which the kio-slave would do the 
reading and, if needed, decoding, e.g. from base64, and then stream that to 
whatever is ).

What do you think? Anything like this meanwhile started by someone else? How 
would you do it? Who wants to cooperate on this? Where would I put the code? 
And else?

Cheers
Friedrich
-- 
Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/



More information about the kde-pim mailing list