Tuesday, 2023-04-25

direc85[m]Whisperfish targets implementing voice/video calls in the future, so having the voice call plugin available sounds a nice to have... We're no strangers to API breakages either so that wouldn't be a big issue 🥲 Probably we'd have a SFOS-version-specific Whisperfish addon RPM to install, or something like that.05:57
dcalisteGood morning pvuorela, how are you ?07:13
pvuoreladcaliste: good morning. i'm good, thanks.07:13
dcalisteMay we chat a bit about the evolution of ExtendedCalendar ? Do you have time to ?07:15
dcalisteOk, thanks. I can imagine two possible evolutions:07:18
dcaliste- keep the status quo, with one global storage for all notebooks. It means that we can keep the current API with a single ExtendedCalendar object to agregate all incidences from different sources. The UID is thus the unique key to access incidences.07:20
dcalisteWe can adopt in ExtendedCalendar the notebook related methods inherited from upstream now that they are deprecated.07:21
dcaliste- or we can move to a new paradigm with one single MemoryCalendar per notebook (the storage will get one file per notebook) and ExtendedCalendar would loose the Calendar API and become something else, agregating various MemoryCalendar.07:28
dcalisteThe former solution is comfortable and is working. It has the drawback that sync methods must change the received UID to be sure to avoid conflict with other UID from other notebooks.07:29
dcalisteIt's a bit ugly, but it's already implemented.07:29
dcalisteIt also requires to tune a bit what we have to allow notebook changing and be sure that sync plugin will be aware of the changes.07:30
dcalisteThe later solution seems more logical and aligned with upstream, but it requires to rewrite ExtendedCalendar extensively. Moreover it requires to add new API to extendedcalendar, because ::incidence(UID) will have no sense anymore. It must become ::incidence(UID, notebookUid).07:31
dcalisteSo it implies a lot of changes in the upper layers, up to the calendar application itself to ensure that UID is always coming with notebookUid.07:32
pvuorelayea. options are something like that. on one hand it's nice to do gradual changes, but then again doing it really properly would require a bigger revamp of the whole thing.07:32
pvuorelanot sure should ExtendedCalendar have such a thing. wouldn't necessarily be needed if each notebook had its own (Extended)Calendar.07:33
pvuorelabut guess we are not in a haste due to upstream changes since it was kf6 which was discussed07:34
dcalisteWell, I like the fact that we have a single object entry gathering the incidences from various sources and presenting them uniformaly to QML for instance. But maybe it's overkill already and calendarworker / calendarmanager could be the place to do the agregation.07:35
dcalisteI agree we're not in a hurry. Just brainstorming what should be the best medium term route to take.07:36
pvuorelathinking also it should be possible to do that in nemo-calendar.07:37
dcalisteActually that's how KDE is doing things, as far as I know (I asked them when they deprecated the notebook API).07:37
pvuorelawas my assumption as well. nice if you got a confirmation there.07:39
pvuorelaone slight inconvenience could be that data loading would need to happen on all the notebooks. for one thing wondering if there could be some master storage thing that would just handle all, thinking aloud.07:40
pvuorelanow the kf5-calendarstorage has a mapping from storage to a single calendar.07:40
dcalisteSo in your opinion, the best route would be to have one notebook <-> one MemoryCalendar <-> one SqliteStorage, and then when doing a range load in calendarworker, the load(date) would be called on the various storages.07:41
dcalisteThat makes sense.07:41
pvuorelawell all that except now thinking if the data loading could be somehow aggregated one place instead of needing to do the same thing for all of the notebooks.07:42
dcalisteWe could have a (truely) ExtendedStorage still exposing the list of available notebooks and doing not noebook related loads, while new SingleStorage would deal with notebook related loads.07:43
pvuorelabut actually not even sure how much we gain now by loading only the needed date ranges. creates complexity but then again the recurring events need to be loaded always anyways.07:43
pvuorelayea, something like that.07:44
dcalisteWell, in term of performances, loading all incidences would be a large memory burden. Incidences are piling up with the years… I think I have something around one thousand incidences in my calendar at the moment.07:45
pvuorelabut is that much? a single events is maybe some hundred of bytes. more if there's a big lump of description text or attendees, but on average maybe not too much.07:46
pvuorela1000 events of 1 kilobyte -> megabyte.07:47
pvuorelaif it matters. do we need day accuracy on loading or would a year suffice?07:48
dcalisteYes maybe. I guess you're right as long as not all of them are transformed into Event objects :)07:48
pvuorelayea. more memory used only when something needs these in a qml model or such.07:49
pvuorelabut again just thinking aloud if all those fancy date loading mechanisms are that much needed.07:50
dcalisteContinuing thinking about single storage separation, having ExtendedStorage loading incidences from various sources means that they should be stored somewhere memory-wise. It can be in MemoryCalendar attached per single storage. Which means that ExtendedStorage will not be attached to an ExtendedCalendar anymore, causing maybe extensive changes in the QML calendarworker… But actually not in the sync plugin because there they will deal with Mem07:53
dcalisteoryCalendar<->SingleStorage directly.07:53
dcalisteWell, I like that direction. I can try designing API for such move MemoryCalendar <-> SingleStorage and an agregating layer in ExtendedStorage (like current API basically) <-> ExtendedCalendar (changhing its API to be UID/NotebookUid aware).07:55
dcalisteThe agregating layer being used basically only in QML calendarworker (UID exposed to manager can easily become there a mangling .from incidence UID and notebook UID).07:56
pvuorelahm, would that keep ExtendedCalendar inheriting from kf5 Calendar or as separate class?07:57
pvuorelathe api is not that big even.07:57
dcalisteNo, and it may even be not needed.07:57
dcalisteThe agregated object cannot inherit Calendar because of non UID unicity between calendars.07:58
dcalisteWhile the Calendar API is UID centred.07:58
dcalisteBreaking the link CalendarEvent::uniqueId == Incidence->uid() would also allow not to change anything above calendarworker actually. We can keep a UID centred API at high QML level while internally incidence UID are not unique between notebooks.08:01
dcalisteTo summarize:08:01
dcaliste- design an API MemoryCalendar <-> SingleStorage by basically restricting to one single notebook all Sqlite operations. This will be almost 1:1 API with what we have now and can be used with minor changes by sync plugins since they are dealing with notebook one by one and doing no agregation,08:03
dcaliste- design a new ExtendedStorage API that would simplify dealing with incidence from various sources. It would be used in calendarworker only to do the load required by the calendarmanager and forge CalendarEvent structures to be passed to the manager. There is no need actually to associate this storage to something looking like a memory calendar.08:05
dcalisteThat plan looks very good to me. It is also solving the long stading issue (in my opinion) of the memory duplication between ExtendedCalendar in the worker and the Event dictionary in the manager representing the same data. No need to write an async version of the SqliteStorage anymore that would send its incidence to another thraed.08:09
pvuorelayea. something like that :)08:16
dcalisteThank you for the brainstorming. Direction looks much clearer to me now.08:19
dcalisteWhen you have time, if you need to prioritise, may you look one how I added the possibility to get search result occurrence sorted without loading all of them ? See mkcal#58 and nemo-qml-plugin-calendar#48.08:21
dcalisteThanks in advance !08:22
dcalisteGreat thanks. So we can talk async on PRs when necessary. Thanks again for your time today and this fruitful discussion.08:29
riniguspoetaster: finished with solid; looking into kservice13:34
poetasterrinigus, you rock.13:34
poetasterrinigus, if you get it finished, I'll push at kio later. then an bunch of apps will build.13:35
riniguspoetaster: looks like doctools is required here as well. I'll package it13:53
rinigushmm, that requires some packages that we don't have. ok, I'll try to skip docboks14:02
poetasterrinigus, yes, I disabled it in one case already, kio has this: # Disable the help: and ghelp: protocol for Flatpak builds, to avoid depending14:13
poetasterPatch101: kio-no-help-protocol.patch14:13
riniguspoetaster: looks that its not needed for kservices either.14:14
rinigusit was optional in cmake14:14
poetasterrinigus, cool.14:14
riniguspoetaster: kservice packaged and available at chum14:24
poetasterrinigus, ok, off I go.15:36
piggzrinigus: poetaster: good to see lots of progress in my inbox when i get in :)17:03
poetasterpiggz, ehrg, still a bit stuck with kio. rinigus is doing the heavey lifting.17:05
poetasterpiggz, more important I finally have https://www.partow.net/programming/exprtk/index.html in babbage. you can do math on sfos.17:05
*** amccarthy is now known as Guest1214517:06
*** amccarthy_ is now known as amccarthy17:06

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!