[Kde-pim] PIM Sprint report: Akonadi Next

[Aaron J. Seigo]

On Friday, November 28, 2014 20.29:42 Kevin Ottens wrote:
> When you say models you meant QAIM subclasses? I'd be rather concerned about
> an almost QAIM only API for data access. I'd expect something more
> agnostic. Definitely live queries which update themselves automatically.

The idea is to have declarative queries (DQ?) which are updated automatically. 
The proposed design is meant to make this possible.

The models would just be there to structure results for use by the UI, 
specifically targeting QML in the long term where QAIM is already mandated by 
design.

In theory, one could iterate the data in a variety of more "raw" ways, but 
generally we envision DQs which populate models as the typical read mechanism.

For creation/mutation, that happens with commands which are formulated 
separately from the models and put into a command queue. When the command is 
successfully carried out the client gets an update notifications and that 
triggers whatever reads are needed.

Typical reactive ....

> Definitely ways to be precise in what you retrieve (right now I tend to
> fetch too much and throw away half of it).

Yes; this is absolutely one of the big problems. When viewing this week in 
your calendar, you really don't need the whole #($*ing calendar going back 3 
years ;)

> But definitely not something
> which mandates collection/item trees or QAIM. That looks like too much
> coupling to me.

It won't be trees as the models need to be usable from QML. So they'll be 
lists at best. One of my hopes is that the new design will be easy enough to 
use on the client side (with the right API plastered on top) that we will be 
able to write as many purpose specific models as we need/want without worry or 
pain.

Basically the opposite of ETM: many simple, purpose built models that are 
cheap enough to write that you can create them even if you might throw them 
away next week.

The points you touched on caused the filling of numerous white boards and 
notebook pages over the last few months :) They are indeed some of the most 
central issues ...

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20141128/28423a0b/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/