Baloo based Qml API for (Active) Mail + Plasma

[Michael Bohlender]

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.


# Both options only return the Ids for the relevant mails, but not the
actual content. 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. (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?

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=sharing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140123/71ba95d3/attachment.html>