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

[Vishesh Handa]

On Thursday 23 January 2014 11:15:02 Michael Bohlender wrote:
> Hello everyone,

Hey Michael

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

I want this for the normal kmail! :D

> 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.
> 

Both APIs are nearly the same, the EmailQuery one is just easier to use. 
Specially since the general Query one barely has any documentation.
 
> 
> # Both options only return the Ids for the relevant mails, but not the
> actual content.

Yup. We don't actually store the content in the indexer any more (unlike the 
Nepomuk days)

> So I would have to do additional round trips to get the
> data. For Active Mail I need:  sender, recipients, topic, status and maybe
> a snipped of the start of the mail. 

You can get the subject of the email directly from Baloo. We duplicate it. 
This is not exposed in the EmailQuery API, but it is in the normal API. Do you 
want to introduce it in the EmailQuery or should I?

> (And a portrait of the sender, but I
> guess that will require and additional roundtrip via kpeople anyway?) I
> also want to offer (bulk) actions for these Mails, namely: mark (un)read,
> mark (un)important and delete.  That leaves me with two options:
> 
> 1) Extend the baloo EmailSearch to offer to also retrieve the metadata and
> do it all in one trip. Start a ItemFetchJob + a ItemModifyJob for each
> (bulk) action the user wants to make.
> (At least that is what I think I have to do, because there is no option in
> the Akonadi API to modify/delete by id?)
> 
> 2) Start an ItemFetchJob that will get me all the Items to for my Ids and
> then I would only have to do the ItemModifyJob because I already have the
> Items.
> 
> I really do not know what option to choose here. What is better for a
> mobile usecase (cpu / memory) wise? Also it is probably related to the
> questions below.
> 
> # Do I need to think about loading the data in parts as in only the first
> 30 Mails and then more if the user requests so?  I might also want to apply
> more filters on the mails or reorder them once they are loaded. Again I
> have two options:
> 
> 1.) do this on the API side and load more into the model if needed
> 
> 2.) do it Client side and have the data in the model but only render a few
> and then more on demand.
> 
> The second option makes more sense to me.
> 
> # The standard Baloo Query has a way to make it asynchronous via a
> QueryRunnable but the specialised PIM one does not AFAIK. This would really
> matter when I also want to get the metadata from baloo. I would  really
> prefer, if the asyc part was handled on the Baloo side. Are there any plans
> to make this happen or does every client have to implement this on his own?
> 

The only way to do async queries is to spawn an extra thread. If required you 
can introduce a new EmailQueryRunnable in the baloo pim library.

> I guess, I will have a lot more questions. But that is it for now.
> Please remember to keep the plasma & pim in CC.
> Thanks for your input.
> 
> Cheers
> 
> Mike
> 
> 
> 
> [1] http://mail.kde.org/pipermail/plasma-devel/2013-November/027148.html
> [2]
> https://drive.google.com/file/d/0B2wLkUtvD4v_MG80amViR2pZZ1k/edit?usp=sharin
> g _______________________________________________
> 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/

-- 
Vishesh Handa