Adding non-date-aligned computable mass events to calendars (le.g. astronomical events)

[Volker Krause]

On Wednesday, 28 July 2021 23:24:20 CEST Friedrich W. H. Kossebau wrote:
> Am Mittwoch, 28. Juli 2021, 20:28:28 CEST schrieb Volker Krause:
> > I think neither iCal (and thus KCalendarCore) nor Akonadi are particularly
> > well suited for these kinds of events. You'd end up creating actual event
> > objects where the recurrence model can't express the algorithm, which is
> > neither efficient nor really working well (as the time range often is
> > infinite).
> > 
> > For many of those the computation is quite fast, so a complex
> > multi-process
> > caching system is also overkill.
> > 
> > My gut feeling would therefore be to put the computation logic into
> > libraries where needed (KF5::Holidays is such an example), and do the UI
> > part in the applications separately, as you say this needs custom UI
> > anyway
> > in many cases.
> 
> Hm, too bad. As one thing I was hoping to get with Akonadi would be to have
> a normalized calendar data model as well as data sources model.
> 
> Sounds like then there is need to add yet another abstraction layer where
> heavy event objects from KCalendarCore would need to be blended with fly-
> weight event shim objects from other data models then, and the same for
> adding/removing/enabling/disabling those data feeds. Because I would guess
> the average user would not want to care whether adding moon phase entries
> means not using Akonadi but another system At least I would fancy a
> normalized UI hiding such implementation details unless without alternative
> :)
> 
> But without having looked closer such additional abstraction layers might
> mean lots of redesign, for a set of features only interesting for a
> minority of current users, and without lots of developer resources
> currently. Sigh, again no low hanging fruits then.
> 
> I guess my git repo commit events Akonadi resources I just started for
> experiments  will suffer from heavy weight objects as well then, at least
> for bigger repos with many commits? Let's see what walls I hit there...

IIRC Sergio had written a Git resource that at some point, might still be 
findable in old playground repos. I don't think the volume of events is a 
problem there, as it's always finite. The main problem are computed events 
occurring indefinitely (if you can't model those with iCal recurrences), 
"unrolling" them with an arbitrary cut-off date is just so much less elegant 
and efficient than computing them on the fly.

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/20210729/6f5c5276/attachment.sig>