[Kde-pim] Baloo based Qml API for (Active) Mail + Plasma

[Christian Mollekopf]

On Thursday 23 January 2014 11.15:02 Michael Bohlender wrote:
> Hello everyone,
> 
> I want to create a Qml API similar to Mark Gaisers QML Calendar stuff for
> Mail. Its main usecase is Kontact Touch Mail, but it should also be useful
> for other applications. E.g. the Plasma guys wanted to be able to access
> our data via something like a QAbstractItemModel that offers a
> qpropery-based API. [1]
> 
> There is no concept of a folder hierarchy in Plasma Active, and I don't
> want to introduce it/make it prominent in the mail client either. Instead
> the idea is to offer (user) predefined searches that act as virtual
> collections/folders to the user.
> 
> * all important mail from account A + B
> * all unread mail related to KDE
> * all mail send by contacts X, Y, Z
> 
> Have a look at this mockup [2] from my GSoC project. The list on the left
> would be the predefined searches and the list on the right the retrieved
> mails (sorted by date) for that search. I think you get the idea.
> 
> I wasn't confident doing something like that with Nepomuk but I think I
> have a fair chance with Baloo. Now I have some questions on how to do this
> architecture wise.  I should probably mention that I have no idea what I am
> doing. So please correct me, if I make wrong assumptions and so on.
> 
> # Baloo currently offers two ways to get to mail data.
> 1) A general Query that is used in baloosearch/milou where I can specify to
> only search for the type email
> 
> 2) A specialised EmailQuery that is currently used in the feature/baloo
> branch of kdepim
> 
> The EmailQuery one seems to be an obvious choice, since it already offers
> the very fine grained search options I want.
> 

It probably makes a lot of sense to use akonadi search folder for that 
(especially from a performance point of view). I think this is a feature that 
we anyways want for all clients, so doing it on the akonadi server instead of 
the client has a couple of advantages imo:
* the folders can be shared among clients
* the search result is persistent
* we can efficiently filter new emails without having to reevaluate all mails

Your work as a client developer then simply becomes displaying that folder 
(all the fetching etc is done through the regular EntityTreeModel). So just 
create an ETM and fetch only the collection you want. This already ensures 
that it is done as efficiently as possible.

So what you would basically do is create a collection for each meta-folder you 
want, and then you set the query you want it to be filled with, and akonadi 
does all the rest from there.

So I'd strongly advise for this solution, as IMO anything else would be a 
waste of resources.

Cheers,
Christian