Re: KCalendarCore plugins/datasources?
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 signature.asc Description: This is a digitally signed message part.
Re: KCalendarCore plugins/datasources?
On Monday, August 12, 2019 6:49:48 AM EDT Daniel Vrátil 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] > > > > Hello, > > Hi Bhushan, > > > > > 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. > > There's KCalendarCore::CalStorage which allows users to write their own > calendar data sources, which could be used as a plugin interface. Extending > the library with a plugin infrastructure would also be OK IMO, but if we want > to have a bunch of plugins to integrate between KCalendarCore and various > backend-specific libraries (e.g. KGAPI, KDAV, Kolab, ...), we should create > KCalendarAddons (or something like that), assuming there's actually any > demand > for this. > > For Akonadi the way it works is that we create an instance of > KCalendarCore::Calendar and directly populate it with entities loaded from > Akonadi. We don't use the CalStorage interface for that as we don't need that > kind of abstraction to integrate between KCalendarCore and Akonadi. > Agree with Dan. I'd say not to put plugins directly into KCalendarCore, but create a new repo for that purpose. If needed.
Re: KCalendarCore plugins/datasources?
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, Hi Bhushan, > > 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. There's KCalendarCore::CalStorage which allows users to write their own calendar data sources, which could be used as a plugin interface. Extending the library with a plugin infrastructure would also be OK IMO, but if we want to have a bunch of plugins to integrate between KCalendarCore and various backend-specific libraries (e.g. KGAPI, KDAV, Kolab, ...), we should create KCalendarAddons (or something like that), assuming there's actually any demand for this. For Akonadi the way it works is that we create an instance of KCalendarCore::Calendar and directly populate it with entities loaded from Akonadi. We don't use the CalStorage interface for that as we don't need that kind of abstraction to integrate between KCalendarCore and Akonadi. Regards, Dan > > > Thanks -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
KCalendarCore plugins/datasources?
[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. Thanks -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature