[Kde-pim] PIM Sprint report: Akonadi Next

[Marco Martin]

On Thursday 27 November 2014 13:06:37 Aaron J. Seigo wrote:
> > > Meaning you need the current akonadi api for the next 4 years working?
> > > (that is something we might provide, so that's an actual question)
> > 
> > I think so..
> > or until the new one is stable, yeah
> 
> I'm not sure what "KDE4libs-based version" of software was being referred to
> here, tbh. (Plasma? Kontact?) In any case ... what would help in being to

Kontact kdelibs4 version under Plasma 5, that is fine, except of the 
integration points below.

> judge the situation is the value and nature PIM data in Plasma 5. How
> critical is it to its users? What are the target integration points? That
> information would be highly useful in helping plans come together that suit
> everyone.

on top of my head:
* calendar: holidays (libkholidays)
* calendar: appointments from akonadi in common with korganizer
* accessing the body of new emails arriving for some extended notification 
thing.. that would be more optional/in the future

perhaps more things could be nice to be accessed from the workspace, but with 
the points above would give feature parity with plasma on kdelibs4

> > could be the straight port be released as "kdepim4support" with all
> > differently named libraries (maybe even with the totality of symbols
> > deprecated), such a way that the redesigned one would be a completely
> > different and not clashing product?
> > once the new one is released, that would get completely deprecated and
> > never released again?
> 
> While a rather nice idea, I personally don't think this is realistic.
> Maintenance will need to be done, people will use whatever is released for
> many years (whether we want them to or not) and actually doing this release
> will take time and energy from the PIM team which is fairly short on those
> things.

that's indeed a good point, such a release would suck up quitte some 
resources.
The only realistic way to avoid that i can think of tough is using some kind 
of bridge between plasma5/kf5 apps and an old akonadi instance.
what maintenance this in turn causes I don't know, for you guys to assess

> One of the reasons we went for modularization of everything and breaking up
> the monolithic SC in the 5.x era was to allow things to be released when
> they are ready and when the team is able to do so. It would be a shame to
> not use that opportunity and rush towards something too quickly just so we
> can e.g. see calendar items in the desktop shell's calendar (among other

So i guess kdepim libraries would be released one by one and then after those 
are stable a kf5 based contact would come?

> things). We also can't take too long as stated earlier ... so we need to
> find what the most optimal time frame is to ensure the PIM stack gets the
> love and quality it needs / deserves and users are not left hanging too
> long.

so for instance for the calendar, could there be a kf5 based library that 
accesses the calendar from the running akonadi that the old kontact is using?
It's still a long maintenance overhead, but it could be at least the smallest 
possible subset to access calendars rather than a whole kontact release.

This i guess would pose no problem if the user facing api of the library would 
be final regardless of the architecture of the underlying akonadi, would 
instead pose a maintainance headache if an old-stile and a new-style calendar 
access libraries end up being released in the end. so it depends what is the 
timeframe of having final api kdepimlibs (would be before or after akonadi 
refactor?)

-- 
Marco Martin
_______________________________________________
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/