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

[Jos van den Oever]

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.

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.

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/