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

[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.

Regards,
Volker

On Wednesday, 28 July 2021 19:26:33 CEST Friedrich W. H. Kossebau wrote:
> Hi,
> 
> I would like to implement what is needed to have the option to see
> environmental/astronomical events (as useful for outdoor activities of all
> kinds, but also infotainment) directly in calendar views. E.g.
> * sunrise/sunset
> * moon phases
> * sun/moon eclipses
> * other artificial and natural sky objects events (satellites, asteroids,
> planets, ...)
> * (weather forecast, but that is a different challenge, with less but
> dynamic data, to be discussed separately once I work on it)
> 
> 
> How do I do an Akonadi resource providing such astronomical event data?
> 
> 
> MOTIVATION
> 
> Right now e.g. lunar phase events are added as frontend-specific addons
> only: * Plasma calendar applet: custom extension, injects moon phase events
> as calendar entries -> https://phabricator.kde.org/D12433
> * KOrganizer decoration plugin (revival up as MR now)
>   -> https://invent.kde.org/pim/kdepim-addons/-/merge_requests/12
> 
> So e.g. Calindori, Kalencar or any other front-end again has to have their
> custom add-ons again, both for injecting the data into the data model as
> well as for any custom data-specific display.
> 
> I would imagine it makes sense to provide such events in a generic way via
> Akonadi to any calendaring UI instead. Because usually if one has interest
> in such events (and their effects, like natural brightness) for planning
> related activity events that information is wanted everywhere, if only as
> context or reference.
> 
> And while certain event data surely benefits from custom display, having
> data provider and frontend rendering decoupled opens the option for more
> reusability (e.g. render type for sunrise/sunset events could be reused for
> other types of events where same display, e.g. a fine line, is useful as
> well or switching data backends when suited without the need to adapt the
> rendering, think someone doing a kstars-engine-powered super-backend).
> 
> 
> QUESTIONS
> 
> I have little if any clue of Akonadi currently.
> 
> With that, i guessed I would do a resource for lunar phases for the start.
> And later one for sunrise & sunset. And then see what else I fancy at the
> time. People could then add that resource with respective config (e.g.
> hemisphere/ location) to their calendar view. And later there could be
> plugins to give those events some special UI/rendering, instead of showing
> just a "normal" event. Like contact birthdays are also fed as events
> through Akonadi and get some special UI.
> 
> For now I created a new resource project from the Akonadi resource template.
> But when starting to look into the API of Akonadi::ResourceBase to
> reimplement, I have no idea yet how to map the mass event data representing
> e.g. lunar phases, which could be any dates where the computation algorithm
> is valid in past & future, onto the data structures and method calls. For
> what I understand I feed items of type KCalendarCore::Event best, as this
> is the data type KOrganizer & other calendaring front-ends use when
> unmarshalling data from Akonadi. I see that KCalendarCore::Event has a
> concept of recurrency, but that one seems to only operate in non-fractional
> multiples of date units? I would guess that having more complex recurrence
> calculation also need a way to be expressed, so the formula can be passed
> on to consumers and processed by them, and most human-oriented use cases do
> not need that, so it is not supported/part of design.
> At the same time Akonadi expects that the number of items in a collection is
> known and available in one set, right? At least a method to implement like
> Akonadi::ResourceBase::retrieveItems(const Akonadi::Collection& 
> collection) suggest that one should be always able to unconditionally
> deliver all items. Which obviously is nothing we want to do for any lunar
> phase events in the past and future ;)
> 
> So, how could one express events which are part of a insanely big number
> (exact number could be estimated by first/last date supported by backend)
> and ideally are only calculated on the fly for windows/views of interest or
> other filter types (like a certain time span)? Is that a concept supported
> by Akonadi in some way? What might be a good similar sample to look at
> (only saw the kdepim-runtime ones for now, which were less similar)?
> 
> Cheers
> Friedrich


-------------- 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/20210728/ab336252/attachment.sig>