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

[Friedrich W. H. Kossebau]

Am Donnerstag, 29. Juli 2021, 09:55:09 CEST schrieb Volker Krause:
> On Wednesday, 28 July 2021 23:24:20 CEST Friedrich W. H. Kossebau wrote:
> > 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. 

Thanks for the hint, would it be this one (which would show messages as 
emails, where I have been more interested in having commits displayed on dates 
for now)?
    https://invent.kde.org/unmaintained/akonadi-git-resource
* Hm, perhaps having a calendar view for emails might be nice as well, at 
least I know that when looking up emails I wrote or received having that 
temporal-spatial layout of calendars to map my memory onto might speed things 
up in some cases, even more with context of other events displayed... ("the 
info I sent you last month after our lunch before you left for the meeting 
with X" :) )

Will take lots of peeks at that old code then, hoping principles & API have 
not changed too much, to flesh out my now initial working resource ( :) ) I 
just pushed at
    https://invent.kde.org/kossebau/git-repo-akonadi-resource
into something which operates nicely along the Akonadi principles/technology, 
so I have some better understanding of that.

> 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)

Cheers
Friedrich