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

[Jos van den Oever]

On Wednesday 29 June 2016 09:30:14 Daniel Vrátil wrote:
> On Wednesday, June 29, 2016 12:59:40 AM CEST Jos van den Oever wrote:
> > How would I get the collection from an Akonadi::Item after doing
> > setAncestorRetrieval(Akonadi::ItemFetchScope::AncestorRetrieval::All) on
> > Akonadi::ItemFetchJob(list, this)?
> > 
> > The code below gives an empty string for collection.remoteId(). The
> > displayName() is empty too.
> > 
> > Akonadi::ItemFetchJob *fetchJob =
> > qobject_cast<Akonadi::ItemFetchJob*>(job); foreach (const Akonadi::Item
> > &item, fetchJob->items()) {
> > 
> >         Akonadi::Item foo(item.remoteId());
> >         Akonadi::Collection collection(item.storageCollectionId());
> 
> Don't use item.storageCollectionId(), use item.prentCollection() right away.
> Only that way you'll get the entire ancestor chain.

parentCollection() works. By concatenating the remoteIds according to maildir 
rules I can often get the file path.

When reading the file, I see that often the payload is two bytes larger than 
the original mail file. Akonady or KMail put an extra \n after the header to a 
total of 3 and a second extra \n after the first multipart separator so that 
also has 3 \n after it.

As a result a hash on the payload can differ from the one on the mail file. I 
guess Akonadi stores the mails as separate pieces and glues them back together 
on request.

> >         while (collection.isValid()) {
> >         
> >             qDebug() << "parent: " << collection.id() << " " <<
> > 
> > collection.remoteId();
> > 
> >             collection = collection.parentCollection();
> >         
> >         }
> > 
> > }
> > 
> > Also, only one parent is retrieved, even when the mail comes from a nested
> > folder.
> > 
> > > 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.
> > 
> > Good point. The checksum would also remain the same. To use that for
> > retrieval would require yet another index. I do not see any other way to
> > make a good permanent identifier for use outside akonadi.
> 
> If your application is long-running, you can spawn an Akonadi::Monitor to be
> notified about any change in the watched emails/folders, allowing you to
> learn about added/removed emails and to update your identifier in case of
> change or move.
> 
> On each start you can do a new ItemFetchJob with
> ItemFetchScope::setFetchChangedSince() to only get a list of Items that
> changed (were added, updated or moved) since the given timestamp to update
> your index. Unfortunately, no way to get a list of removed Items this
> way....

I guess that looks at the mtime.

Would using the gid() instead make sense? In theory it's unique, but an 
unfriendly/buggy sender could generate mails with identical Message-ID 
headers.

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/