| 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 |
|---|---|---|
| dcaliste | Good morning pvuorela, how are you ? | 07:13 |
| pvuorela | dcaliste: good morning. i'm good, thanks. | 07:13 |
| dcaliste | May we chat a bit about the evolution of ExtendedCalendar ? Do you have time to ? | 07:15 |
| pvuorela | sure. | 07:18 |
| dcaliste | Ok, 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 |
| dcaliste | We 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 |
| dcaliste | The 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 |
| dcaliste | It's a bit ugly, but it's already implemented. | 07:29 |
| dcaliste | It 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 |
| dcaliste | The 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 |
| dcaliste | So 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 |
| pvuorela | yea. 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 |
| pvuorela | not sure should ExtendedCalendar have such a thing. wouldn't necessarily be needed if each notebook had its own (Extended)Calendar. | 07:33 |
| pvuorela | but guess we are not in a haste due to upstream changes since it was kf6 which was discussed | 07:34 |
| dcaliste | Well, 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 |
| dcaliste | I agree we're not in a hurry. Just brainstorming what should be the best medium term route to take. | 07:36 |
| pvuorela | thinking also it should be possible to do that in nemo-calendar. | 07:37 |
| dcaliste | Actually that's how KDE is doing things, as far as I know (I asked them when they deprecated the notebook API). | 07:37 |
| pvuorela | was my assumption as well. nice if you got a confirmation there. | 07:39 |
| pvuorela | one 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 |
| pvuorela | now the kf5-calendarstorage has a mapping from storage to a single calendar. | 07:40 |
| pvuorela | kf5-calendarcore... | 07:41 |
| dcaliste | So 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 |
| dcaliste | That makes sense. | 07:41 |
| pvuorela | well 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 |
| dcaliste | We 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 |
| pvuorela | but 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 |
| pvuorela | yea, something like that. | 07:44 |
| dcaliste | Well, 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 |
| pvuorela | but 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 |
| pvuorela | 1000 events of 1 kilobyte -> megabyte. | 07:47 |
| pvuorela | if it matters. do we need day accuracy on loading or would a year suffice? | 07:48 |
| dcaliste | Yes maybe. I guess you're right as long as not all of them are transformed into Event objects :) | 07:48 |
| pvuorela | yea. more memory used only when something needs these in a qml model or such. | 07:49 |
| pvuorela | but again just thinking aloud if all those fancy date loading mechanisms are that much needed. | 07:50 |
| dcaliste | Continuing 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 Mem | 07:53 |
| dcaliste | oryCalendar<->SingleStorage directly. | 07:53 |
| dcaliste | Well, 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 |
| dcaliste | The 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 |
| pvuorela | hm, would that keep ExtendedCalendar inheriting from kf5 Calendar or as separate class? | 07:57 |
| pvuorela | the api is not that big even. | 07:57 |
| dcaliste | No, and it may even be not needed. | 07:57 |
| dcaliste | The agregated object cannot inherit Calendar because of non UID unicity between calendars. | 07:58 |
| dcaliste | While the Calendar API is UID centred. | 07:58 |
| dcaliste | Breaking 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 |
| dcaliste | To 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 |
| dcaliste | That 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 |
| pvuorela | yea. something like that :) | 08:16 |
| dcaliste | Thank you for the brainstorming. Direction looks much clearer to me now. | 08:19 |
| dcaliste | When 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 |
| dcaliste | Thanks in advance ! | 08:22 |
| pvuorela | sure | 08:26 |
| dcaliste | Great thanks. So we can talk async on PRs when necessary. Thanks again for your time today and this fruitful discussion. | 08:29 |
| rinigus | poetaster: finished with solid; looking into kservice | 13:34 |
| poetaster | rinigus, you rock. | 13:34 |
| poetaster | rinigus, if you get it finished, I'll push at kio later. then an bunch of apps will build. | 13:35 |
| rinigus | poetaster: looks like doctools is required here as well. I'll package it | 13:53 |
| rinigus | hmm, that requires some packages that we don't have. ok, I'll try to skip docboks | 14:02 |
| poetaster | rinigus, yes, I disabled it in one case already, kio has this: # Disable the help: and ghelp: protocol for Flatpak builds, to avoid depending | 14:13 |
| poetaster | Patch101: kio-no-help-protocol.patch | 14:13 |
| rinigus | poetaster: looks that its not needed for kservices either. | 14:14 |
| rinigus | it was optional in cmake | 14:14 |
| poetaster | rinigus, cool. | 14:14 |
| rinigus | poetaster: kservice packaged and available at chum | 14:24 |
| x2s | https://www.nitrokey.com/news/2023/smartphones-popular-qualcomm-chip-secretly-share-private-information-us-chip-maker | 15:01 |
| poetaster | rinigus, ok, off I go. | 15:36 |
| piggz | rinigus: poetaster: good to see lots of progress in my inbox when i get in :) | 17:03 |
| poetaster | piggz, ehrg, still a bit stuck with kio. rinigus is doing the heavey lifting. | 17:05 |
| poetaster | piggz, 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 Guest12145 | 17:06 | |
| *** amccarthy_ is now known as amccarthy | 17:06 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!