KCalendarCore plugins/datasources?

[Volker Krause]

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]
> 
> Hello,
> 
> 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.

The main use-case I see for this is using the platform calendar on systems 
like Android that have such a concept, rather than an Akonadi backend, ie. I'd 
not see this as a direct interface to e.g. a CalDav server.

KCalCore is certainly the right data model for this regarding events/todos and 
a collection thereof, but it might not model enough of what is behind that, 
such as multiple calendars fed from different backends as present on Android 
or Akonadi, as well as API interacting with those (e.g. triggering a re-sync).

For Akonadi that code is in akonadi-calendar and/or calendarsupport (I'm not 
too familiar with the details, IIRC this is largely Sergio's work). For 
Android see https://developer.android.com/guide/topics/providers/calendar-provider, esp. the Calendar table.

I think a proper data source abstraction would need to model this part too, 
without going too much into an account concept, that should be left to the 
corresponding backend.

For content access KCalCore::Calendar is probably a decent abstraction, it 
might be worth checking if the Akonadi code is extending or breaching that 
abstraction for some reason, so we don't miss anything here.

A low-tier plugin system would be quite attractive then IMHO, it could for 
example also avoid some of the current Plasma/Akonadi calendar integration 
complexity. Prototyping that outside of KCalCore initially makes sense 
probably, but I could see that go into KCalCore eventually.

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20190812/a56df60f/attachment.sig>