[Kde-pim] PIM Sprint report: Akonadi Next

[Kevin Ottens]

On Friday 28 November 2014 22:26:21 Aaron J. Seigo wrote:
> 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.

Ah good. Thanks for the clarification, makes way more sense to me now.
 
> 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 ....

Yup! :-)

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

Tell me about it. :-)

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

OK, thanks for the extra information.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com

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