From kde-frameworks-devel  Mon Aug 12 13:27:28 2019
From: Allen Winter <winter () kde ! org>
Date: Mon, 12 Aug 2019 13:27:28 +0000
To: kde-frameworks-devel
Subject: Re: KCalendarCore plugins/datasources?
Message-Id: <13867444.tv2OnDr8pf () zazzy>
X-MARC-Message: https://marc.info/?l=kde-frameworks-devel&m=156561647606213

On Monday, August 12, 2019 6:49:48 AM EDT Daniel Vr=E1til wrote:
> On Sunday, 11 August 2019 12:12:10 CEST Bhushan Shah wrote:
> > [I am not subscribed to kde-pim list, please keep me or k-f-d in CC]
> >=20
> > Hello,
>=20
> Hi Bhushan,
>=20
> >=20
> > So yesterday I was discussing this with the Volker in #kde-devel, that
> > currently kcalcore doesn't provide a "plugin interface" to create a
> > various data sources like, file storage, online/cloud storage, or
> > akonadi storage, and Akonadi have it's own custom code for this.
> > Would it make sense to have something like this in kcalcore itself?
> > Volker mentioned to me that it needs close look at Akonadi based
> > implementation and trying to finalize API.
>=20
> There's KCalendarCore::CalStorage which allows users to write their own=20
> calendar data sources, which could be used as a plugin interface. Extendi=
ng=20
> the library with a plugin infrastructure would also be OK IMO, but if we =
want=20
> to have a bunch of plugins to integrate between KCalendarCore and various=
=20
> backend-specific libraries (e.g. KGAPI, KDAV, Kolab, ...), we should crea=
te=20
> KCalendarAddons (or something like that), assuming there's actually any d=
emand=20
> for this.
>=20
> For Akonadi the way it works is that we create an instance of=20
> KCalendarCore::Calendar and directly populate it with entities loaded fro=
m=20
> Akonadi. We don't use the CalStorage interface for that as we don't need =
that=20
> kind of abstraction to integrate between KCalendarCore and Akonadi.
>=20
Agree with Dan.
I'd say not to put plugins directly into KCalendarCore, but create a new re=
po for that purpose.
If needed.