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

[Friedrich W. H. Kossebau]

Jeudi, le 28 avril 2011, à 23:30, Friedrich W. H. Kossebau a écrit:
> 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?

Really no comment anyone? :)

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/