[Kde-pim] Handling Virtual Collections/Resources in Akonadi applications

[Stephen Kelly]

Hi,

This is something I wanted to bring up in the sprint in Berlin in April, but I only got a chance to discuss it with toma there, and never sent my notes to the list for discussion.

Here now are those notes.

We have been talking about the concepts and usecases for while, and I've been thinking about how the EntityTreeModel should treat them.

Currently, when it is created, the model retrieves a list of collections from the server matching the mimetypes configured in the Monitor. If the contentMimeTypes of the Collection match the mimetypes watched by the Monitor, the Collection should be inserted into the model. The model then arranges those collections into a tree and optionally fetches their items to populate the model. Currently virtual collections do not have content mimetypes, which means that they are not returned to the model to populate it. This means that applications which are not akonadiconsole (which does no mimetype filtering) show no virtual resources/collections by default. This is actually no bad thing.

One usecase for virtual collections is the search folder. As I understand the intention, we would set up a Nepomuk query and an akonadi agent would use the results of the query to link Items into virtual Collections. So, for example run a search for 'giraffe', KMail would put a query into the agent and show a virtual collection containing the search result. It would be possible to run multiple separate searches and keep them around, or expire and remove them by user action. Additionally, we could have Lion Mail showing a virtual collection of emails tagged as with relevant tags to the current activity, or KOrganizer showing a virtual collection of emails related to the selected event or whatever. Although all of these virtual collections contain emails, they should not all show up in each application, or at least, not without being requested. KMail shouldn't show a virtual collection for the tagged emails being shown in lion mail for example, or the results of a contact search in KAddressBook. It might make sense for Mailody and KMail to show the same search virtual collections. That's up to the maintainers to decide, but the point is that many virtual collections will be known to the akonadi server, but applications need to have control over virtual collections they show. 

The way to do that would be to explicitly set the virtual resource as being monitored and add code to the ETM to always include resources which are explicitly monitored.

A mail application could then configure a monitor something like this:

// Get a tree of concrete mails
m_monitor = new Monitor(this);
m_monitor->setMimeTypeMonitored("text/rfc822" );
mailModel = new MailModel(m_monitor, session);

And in the slot of a search action,

slotSearch(searchTerm)
{
// Run a job to create a new search resource with a SPARQL query. Give the results virtual resource the identifier ident;
QByteArray ident =  "main_mail_app_search_" + qRand();

new SearchQueryCreateJob( "text/rfc822 contains='" + searchTerm+ "' ", ident );

// when the results are available in Akonadi, make them part of the model:
m_monitor->setResourceMonitored(ident);
}

The virtual resource could then be removed with another action, or whatever the Thomases decide. 

Most of the work on this will be done by me anyway, but I'd like to get good idea/bad idea concensus. Any thoughts on that?

Steve.


_______________________________________________
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/