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

[Volker Krause]

On Thursday 28 April 2011 23:30:45 Friedrich W. H. Kossebau wrote:
> 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.

Makes a lot of sense to me.

> 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. 

The akonadi kio-slave is the obvious place to put this. OTOH it's completely 
type-independent right now (ie. it just passes through the data without 
understanding its content), which would need to be changed. Still, in the 
worst case this could be solved with type-specific plugins again, if we ever 
need that (emails are not the only thing that can have attachments, even if by 
far the most common one). So, I would just go for the akonadi kio-slave for 
this.

Additionally, this would probably tie in nicely with the attachment URIs we 
are using for Nepomuk indexing. They have the form akonadi:<itemid>#<content 
index>, where content-index is a unique identifier for email parts (see 
KMime::ContentIndex). The kio-slave doesn't handle the extra info though and 
just returns the corresponding mail. So, when using krunner to full-text 
search and selecting an attachments in the results, the corresponding mail is 
opened instead.

> 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 ).

Yes, there is probably room for improvements, on all levels, ie. including 
KMime and Akonadi as well. But given the typical access patterns (like loading 
a single attachment), I'm not sure if that really the most important 
bottleneck.

> What do you think? Anything like this meanwhile started by someone else?

Not that I know of.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20110507/9036688a/attachment.sig>
-------------- next part --------------
_______________________________________________
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/