[Kde-pim] PIM Sprint report: Akonadi Next

[Christian Mollekopf]

On Monday 01 December 2014 10.34:33 Milian Wolff wrote:
> 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.

I am looking at KJob, but I'm not sure whether it is a good fit after all (I 
thought it is initially). Certain features I'd like to have are not available, 
and certain features KJob provides are not really necessary, and I'd like to 
avoid just misusing KJob because it exists. I will definitely reevaluate this 
once I have a better understanding of what exactly is required (and pass it on 
to kcd for comment).

In any case I'll want a compatibility bridge for existing kjobs, since I'm not 
going to rewrite all code at once.

I'll also have a look at threadweaver, but I really want to abstract whether 
we're using asynchrony using threads or the eventloop.
_______________________________________________
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/