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

[Tobias Koenig]

On Wed, Aug 12, 2009 at 01:27:54PM +0100, Stephen Kelly wrote:
> Hi,
Hej,

> 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.
Actually it is not an agent that does the linking but the Akonadi server itself (or better said
the nepomukmanager inside the Akonadi server). See kdesupport/akonadi/server/src/nepomukmanager.cpp

> 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.
Exactly, however a DeleteSearchJob is still missing ;)

> 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?
Hmm, we need an identifier for this for sure, but maybe we can add another parameter

enum Visibility
{
  Global,       ///< Search collection is visible for all application.
  Application,  ///< Search collection is only visible to application with the given identifier.
};

So the SearchCreateJob would have the following ctor

  SearchCreateJob(const QString &name, const QString &query, Visibility visibility, const QString &identifier);

The created search collection would contain a special SearchVisibilityAttribute that contains the Visibility
flag and the identifier.

The ETM would provide a method 'setSearchSession(const QString&)' where the identifier of the application is
passed that uses this instance of ETM (e.g. kmail would pass 'kmail' ;)). Now the ETM could query all search
collection and evaluate their SearchVisibilityAttribute. If the Visibility is set to Global, it is always
included, if Visibility is set to Application, the collection is only included if the identifiers match.

Comments?

Ciao,
Tobias
-- 
Separate politics from religion and economy!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20090812/18a6bfe4/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/