[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] PIM Sprint report: Akonadi Next
From:       Kevin Ottens <ervin () kde ! org>
Date:       2014-11-28 19:29:42
Message-ID: 2203339.gPttumofSz () wintermute
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hello,

On Wednesday 26 November 2014 13:16:49 Daniel Vrátil wrote:
> API-wise, while we can't completely get rid of the "imperative" API of
> having jobs, the core method to provide access to data would be through
> models. Making use of storage data versioning, on update the model simply
> requests changes between current and last revision of the stored data. This
> should prevent us from ending up with overcomplicated beast-models like
> ETM.

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. Definitely ways 
to be precise in what you retrieve (right now I tend to fetch too much and 
throw away half of it). But definitely not something which mandates 
collection/item trees or QAIM. That looks like too much coupling to me.

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

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

["signature.asc" (application/pgp-signature)]

_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[prev in list] [next in list] [prev in thread] [next in thread]