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

[Volker Krause]

On Thursday, 29 July 2021 18:31:32 CEST Friedrich W. H. Kossebau wrote:
> 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

Yep, I think that's it.

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

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.

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/20210730/24ca2331/attachment.sig>