[Kde-pim] retrieving a resource from an akonadi:/ url

[Daniel Vrátil]

On Tuesday, June 28, 2016 9:43:04 PM CEST Jos van den Oever wrote:
> On Tuesday 28 June 2016 17:00:42 Daniel Vrátil wrote:
> > On Tuesday, June 28, 2016 2:31:58 PM CEST Jos van den Oever wrote:
> > > On Tuesday 28 June 2016 15:14:51 Daniel Vrátil wrote:
> > > > On Tuesday, June 28, 2016 10:54:15 AM CEST Jos van den Oever wrote:
> > > > > Hi all,
> > > > > 
> > > > > I'm writing a simple application on which I'd like to drop emails.
> > > > > Dropping
> > > > > mails from kmail gives an akonadi:/ url. How can I talk to akonadi
> > > > > to
> > > > > get
> > > > > the actual raw mail? The mails are all in maildir, so getting the
> > > > > file
> > > > > path
> > > > > would be fine too.
> > > > 
> > > > Hi,
> > > > 
> > > > you have two options. You can use the Akonadi KIO slave that is part
> > > > of
> > > > kdepim-runtime to get the email - just pass the URL to KIO::get(),
> > > > that
> > > > should work. Alternatively you can use Akonadi directly. The URL is
> > > > something like akonadi://?id=1234, so you use Akonadi::ItemFetchJob to
> > > > retrieve an Akonadi::Item  with that ID.
> > > 
> > > Thanks for the pointer Dan.
> > > 
> > > Could you explain a bit through which parts of the akonadi:
> > > infrastructure
> > > both of these options go? Are there any ports or sockets involved? Does
> > > this go via an private dbus api?
> > 
> > In both cases this goes through sockets and optionally a little bit of
> > DBus
> > API.
> > 
> > Akonadi::ItemFetchJob will talk to the Akonadi Server through a socket. If
> > Akonadi Server finds out that it needs to retrieve the actual email data
> > from the maildir storage, it will do a DBus call to the Maildir resource,
> > the resource uploads the email data back to Akonadi Server through a
> > socket
> > (the same one your app talks to the Server). The Server then sends the
> > data
> > back to your application through the socket again.
> > 
> > In case of the KIO Slave there's the added indirection of your application
> > talking to the KIO Slave through KIO's socket, then the KIO Slave does the
> > same think as described above and relays the result back to your
> > application trough the KIO socket.
> > 
> > If you are concerned about performance, the direct API is the way to go as
> > it allows you to tune some more details (like what all to fetch, see [0]
> > and [1]).
> 
> That's pretty clear. I guess there's a MySql access in there as well to find
> out how the id links to the remoteId.

Indeed forgot that one :-)

> 
> I've now managed to get the complete payload. with QList<Item> I can get
> several items at a time. Performance is not an issue I'm worried about. The
> aim is to be able to link to mails from another application. I do not want
> to rely on akonadi identifiers. Luckily emails do not change, so I can use
> a checksum like sha1 as the reference.
> 
> I've also tried Ingos suggestion to use removeId. For maildir, this gives
> the filename, but not the complete path. Perhaps
> setFetchRemoteIdentification(true) can help to get all collections
> remoteIds from which I can then build a path.

setFetchRemoteIdenfitication() affects whether Item::remoteId() should be 
retrieved or not, so that won't help you much. You could however enable full 
ancestor retrieval, which will give you full chain of Akonadi::Collections 
that the Item belongs to. You can then use the Collection's remoteID to build 
a fully unique path.

However using remoteID with maildir has one big problem: maildir actually 
encodes flags (like the "seen" flag) into the file name, so when user marks an 
email as read (or changes some other flags), the file name changes and thus the 
remoteID changes. In this case Akonadi ID is actually more stable.


Dan

> 
> Cheers,
> Jos
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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/


-- 
Daniel Vrátil
www.dvratil.cz | dvratil at kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20160629/0dd99559/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/