[Kde-pim] PIM Sprint report: Akonadi Next

[Milian Wolff]

On Sunday 30 November 2014 19:08:27 Christian Mollekopf wrote:
> On Friday 28 November 2014 20.29:42 Kevin Ottens wrote:
> > 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.
> 
> Aaron already clarified most things already, but let me add a couple of
> points =)
> 
> I'm obviously borrowing ideas from other async and reactive frameworks,
> including zanshin ;-) I intend to write in parallel with Akonadi Next (is
> that a name now?), a generic async library.
> 
> The scope will be:
> * an async imperative style async API (jobs)
> * composable jobs
> * async control flow (map(for)/filter(if)/reduce) for jobs
> * reactive collections
> * perhaps also generic models on top of reactive collections (like what's in
> zanshin)

Could this be added to KJobs instead of reinventing the wheel completely? Or 
why is KJobs not a good base? ThreadWeaver also does some of this stuff, but 
it's bound to use threads, which might or might not be desired. Definitely 
look at these frameworks please, before reinventing (parts of) the wheel.

> This library should become a general purpose async library (kasync?), that
> we would rely on for a large part of the API.
> 
> I should spec out some of the features I want to have, write a blogpost, and
> start a discussion.... I already did some planning during the pim sprint
> with daniel.
> 
> Once that is ready I'll definitely get back to you for your input ;-)


-- 
Milian Wolff
mail at milianw.de
http://milianw.de
_______________________________________________
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/