<div dir="ltr"><div><div>Hello everyone,<br><br></div><div>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] <br>
</div><div><br></div><div>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. <br>
<br>* all important mail from account A + B<br>* all unread mail related to KDE<br></div><div>* all mail send by contacts X, Y, Z<br><br></div><div>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.<br>
</div><div><br></div>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.<br>
<br></div><div># Baloo currently offers two ways to get to mail data. <br>1) A general Query that is used in baloosearch/milou where I can specify to only search for the type email<br><br></div><div>2) A specialised EmailQuery that is currently used in the feature/baloo branch of kdepim<br>
<br></div><div>The EmailQuery one seems to be an obvious choice, since it already offers the very fine grained search options I want.<br><br><br></div><div># 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:<br>
<br></div><div>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.<br></div><div>(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?)<br>
<br><div>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.<br><br></div><div>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. <br>
<br><br># 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: <br>
<br>1.) do this on the API side and load more into the model if needed<br><br></div><div>2.) do it Client side and have the data in the model but only render a few and then more on demand.<br><br></div><div>The second option makes more sense to me.<br>
<br><br></div><div># 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?<br>
<br></div><div>I guess, I will have a lot more questions. But that is it for now.<br></div><div>Please remember to keep the plasma & pim in CC.<br></div><div>Thanks for your input. <br></div><div></div><div><br></div>
<div>Cheers<br><br></div><div>Mike<br></div><div><br><br><br>[1] <a href="http://mail.kde.org/pipermail/plasma-devel/2013-November/027148.html">http://mail.kde.org/pipermail/plasma-devel/2013-November/027148.html</a><br>[2] <a href="https://drive.google.com/file/d/0B2wLkUtvD4v_MG80amViR2pZZ1k/edit?usp=sharing">https://drive.google.com/file/d/0B2wLkUtvD4v_MG80amViR2pZZ1k/edit?usp=sharing</a><br>
</div></div></div>