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

[Friedrich W. H. Kossebau]

Am Freitag, 30. Juli 2021, 07:35:37 CEST schrieb Volker Krause:
> On Thursday, 29 July 2021 18:31:32 CEST Friedrich W. H. Kossebau wrote:
> > > I don't think the volume of events is a
> > > problem there, as it's always finite.
> > 
> > But with high volumes also finite numbers still can be a problem, no?
> > While
> > I could see why the Akonadi center would need to have a complete list of
> > all item ids in a collection as minimum as well as their type, I would
> > have
> > expected that queries for the individual payloads would have some option
> > for additional windowing/filter mechanisms below the collection
> > granularity, for use cases like "only want all events with an instance in
> > current month", so resources with own filter capability could limit the
> > data transferred to just those items which match the filter condition. Is
> > there something like that already in place perhaps (not yet explored all
> > API in detail)?
> > 
> > I could imagine that such windowing as well as limited cache for a
> > resource
> > could somehow allow to handle theoretically infinite data, where knowing
> > just the ids of items in the window is fine. And making things more
> > complex
> > 
> > :P But well, perhaps also faster in some other more relevant cases, as
> > 
> > server/ resource-side filtering might enhance things for other cases with
> > big collections by principles as well.
> > (Beware, I have no related background/experience, never dealt with IMAP or
> > other caching-related database access, so making things up while I run
> > into
> > them, happy to be treated as curious amateur here :) and be given some key
> > terms or pointers to where to read up to learn more)
> 
> Right, a time window query API would be very convenient from a application
> developer POV. The challenge with that however is that it's difficult to
> come up with an efficient index for which item is in a given time interval.
> For iCal it's due to the complex recurrence rules, for email it's due to
> threading.

(Time as filtering condition is just an example, I could imagine there might 
be other conditions to pre-select the results delivered, e.g. contacts with 
irc addresses).

Okay, thanks for the discussion so far. I will keep this challenge in the back 
of my mind while hopefully exploring more of Akonadi in the coming weeks, both 
client-side & backend-side...


And I just had another use-case where another resource would come handy: 
seeing photos taking on an event, instead having to find digikam in the app 
list, waiting for it to start and then navigating again to the respective date 
in yet another calendar view... 

Which triggered another curiousity, and I found that the Zeitgeist project 
still is alive at https://gitlab.freedesktop.org/groups/zeitgeist ... but I 
guess nothing can feed it from KDE software side? And kactivities-stats seems 
to not have timestamps in any data, so also not helpful...

So much for things in the past, but also for the future there were events I 
would have liked today to be available on demand in the calendar view to plan 
the day:
collection time table of nearby letterbox, closing time of nearby bottles 
supermarket, bus time table, ... now how to get all that feed in ... :)

And even more perfect would be if there were plugins possible for event 
subtypes (cmp. QAbstractItemDelegate for QAIM), so one could have custom UI 
(rendering, interaction) for custom event types (kparts-like)... doh, the 
dream list fills up quickly ;) but that could also be sleep time coming up :P

Cheers
Friedrich