Tuesday, 2020-08-11

*** frinring_ is now known as frinring01:18
*** zbenjamin is now known as Guest4636201:47
*** zbenjamin_ is now known as zbenjamin01:47
dcalisteHello chriadam, how are you ?07:17
chriadamhi dcaliste07:17
chriadamI'm well thanks07:17
chriadamhow are you?07:17
dcalisteI'm fine thank you.07:18
chriadamthat's good07:18
chriadamdid you get my email earlier?  I have had no chance to review the PRs yet unfortunately :-(07:18
chriadamI have poked jpetrell and pvuorela about those in a meeting just earlier today, however07:18
dcalisteYes, no problem, thanks for asking to them also.07:19
chriadamthank you for your patience07:19
chriadamit has been 3 weeks and I have not progressed those :-(07:20
dcalisteI didn't work on anything related neither this week. But I've been using the CalDAV failure branch for all the time, and with the mkcal patch for alarms, it's performing well.07:20
chriadamah excellent!07:20
chriadamthat is good news07:20
dcalisteYes, I'm quite happy with it. Modifying parent of recurring event, adding exceptions, modifying them, adding all day events repeating some days, all went well.07:21
chriadamnice one07:22
dcalisteIt's tested only with my CalDAV provider though (based on OpenXchange), so it may not be that marvelous with other servers, but well !07:22
dcalisteThe failure part is quite difficult to test "alive" though, because it requires to have some issues with the network or the server response.07:23
chriadamindeed, can ask Bree to do some more rigorous testing with different servers once we have merged the PRs, to ensure no regressions.07:23
chriadamyes, failure mode testing is often tricky to do, except for mockable / unit testable cases.07:23
dcalisteIndeed, I'm thinking of adding some unit tests to check the handler routine behaviours. But not done yet.07:24
dcalisteWhen you will have a minor window for those MRs, we discussed it last meeting, but I would suggest you to look at the kcalcore MR about volatile properties first : https://git.sailfishos.org/mer-core/kcalcore/merge_requests/1907:26
chriadamflypig: will you have any time to look into the calendar related ones this week, by any chance?  if so ^^07:26
dcalisteThe patch is taken from upstream, with a minor modification to ensure that mkcal is restoring properly the volatile properties.07:28
dcalisteI will try to have this minor modification upstreamed in the coming days.07:28
flypigThanks for the prod chriadam. I'm a bit out of the loop, but I'll take a look and try to do something useful.07:29
dcalisteI'm not sure they will accept it though. In my opinion, there is a minor  inconsistency in their implementation, because we can add X-KDE-VOLATILE- type properties with the addNonKDECustomProp() API, and these props will be added in the non volatile. But later on, they won't be exported in serialisation to iCal format because they start with X-KDE-VOLATILE, which is fine.07:30
dcalisteBut, then, why not put them in the volatile QSet from the start ? Otherwise it creates some issues elsewhere when accessing the list of properties with the API.07:30
chriadamflypig: thank you - basically, dcaliste was looking into how to report (for individual events) whether sync failed for that event.  upstream kcalcore has concept of "volatile" properties, which can be used to report these.07:31
dcalisteThank you flypig.07:31
chriadamflypig: so there is that PR, then one in nemo-qml-plugin-settings, then one in jolla-calendar.07:31
chriadamand I guess one in caldav.  basically, setting this property "sync failed!" and exposing it to QML, then in jolla-calendar, showing some UI if it was a sync failure.07:31
dcalisteExact, but the QML binding is in nemo-qml-plugin-calendar ;)07:32
flypigOkay, that's very helpful; thanks for the explanation.07:32
chriadamMartin is going to look at the jolla-calendar PRs from UI design standpoint, but the kcalcore/nemo-qml-plugin-calendar etc side needs review also.07:32
chriadamoops, yes, nqpcalendar not settings07:32
chriadammy brain is mush ;-)07:32
dcalisteBasically, we agree in nemo-qml-plugin-calendar of a storage format in terms of KCalCore volatile properties per event to mark each of them with an out-of-sync status with respect to upstream.07:33
dcalisteThen, the UI can display this out-of-sync status to the user.07:33
dcalisteThe CalDAV plugin is modified to mark the failing events with this particular volatile properties.07:34
chriadamprevents case where user misses an appointment because the date/time changed on server but the change wasn't successfully synced to device - currently there is no UI indication of such an issue, with dcaliste's changes the UI would at least show the user that they may need to manually check.07:35
chriadamin any case, if you would have some time to review those, I would greatly appreciate it, as I doubt I will have time this week, unfortunately.07:36
chriadamalso pvuorela ^07:37
dcalisteYep, that's the idea. Later on, it may be completed with report of the sync log (for events that could not be downloaded or inserted in the local DB for whatever reason) using the Buteo QML bindings I'm still working on… But I'm not happy with any idea I got from a UI point of view.07:38
chriadamdefinitely a longer-term task ;-)07:39
flypigchriadam, do we have a bug number for those tasks yet?07:39
flypigThe volatile properties particularly, I mean.07:39
chriadamI don't recall.  there was a TJC associated IIRC07:40
flypigOkay, I may create one then, otherwise I lose track.07:40
flypigI guess the actual issue is about identifying sync failures, rather than introducing volatile properties.07:41
dcalisteIf we want to use the new forum bug report, there is this one : https://forum.sailfishos.org/t/calendar-sync-should-continue-with-next-item-on-error/50007:41
dcalisteflypig: exact. The volatile properties are a way to mark events without cluttering the iCal serialisation with if (blabla) remove this prop-before-exporting.07:42
dcalisteBecause it's the way they are doing it automatically upstream in KCalendarCore.07:42
flypigOkay, great. This'll make a nice improvement.07:42
flypigThanks also for the forum link; that's helpful.07:42
flypigSo currently if one item fails to sync, the whole calendar is dead?07:44
dcalisteYes. Even worst in my opinion, if you have several calendar, a single failure somewhere stops all the process.07:44
chriadampart of dcaliste's improvements is to address this.  instead, each individual failure will be marked, but the sync will continue.07:45
dcalisteModifying this behaviour as chriadam is describing, implies a lot of internal changes in the CalDAV plugin though.07:45
dcalisteIt's in my 'failure' branch at the moment.07:46
*** Ischwitch is now known as Ingvix07:47
flypigSo, these three other PRs (kcalcore MR#19, nemo-qml-plugin-calendar MR#61, jolla-calendar MR#266) don't solve the overall problem, they're just enablers?07:48
dcalisteThey are there to expose (some of the) failures to the user.07:49
flypigOkay, thanks. That sounds great.07:49
flypigWhat sort of things prevent the sync? Is there a danger of bad things accumulating in storage (things that used to break everything, but now only break one event)?07:49
dcalisteThat's a valid concern, indeed.07:50
dcalisteThere are several possibilities:07:50
chriadamcan be something as small as a malformed iCal received from a server, which our parser chokes on.07:50
dcaliste- a network failure when downloading the etags -> still stops the sync but for this calendar only,07:50
dcaliste- a network failure when downloading the remote changes -> don't stop the sync anymore, but only report sync failure in the log.07:51
dcaliste- a network failure for a sungle event when uploading a local change -> event is marked as out of sync, try to continue upstreaming for others.07:51
dcaliste- a remote deletion that fails locally -> marked as deleted remotely but failed on device, will try it again next time, with the same result I assume.07:52
dcaliste-  a remote modification that fails to be applied locally -> marked as out of sync, will try again next sync and may fail again.07:53
flypigchriadam's case would fall under this, I guess.07:53
dcaliste- a remote addition that cannot be added locally -> nothing is reported at the moment, just the logs are marked as failed but the rest tries to continue.07:54
chriadamor this case07:54
flypigSo in all those cases they'll either fix themselves on the next sync, or remain unfixable indefinitely.07:54
flypigNo damage caused by the failed sync itself.07:55
dcalisteSo indeed, failures may pile up at each sync. But at the moment, it's the same in my opinon, if it's not a network failure, the sync will fail each time, and nothing will sync anymore.07:55
flypigOkay, I'm clear on that then. Thanks!07:55
dcalisteThe idea here is to sync as much as possible and let warn the user on failures. If it's not network failures, then there should be a way to warn the user that the event is faulty, thus the three MRs you mentioned earlier.07:56
dcalisteBecause now, it's simple to see that there is a problem, even without looking at the logs, nothing is syncing anymore.07:57
dcalisteBut after the MR, many minor sync issues may pass without notice of the user because 99% of the modifications are synced alright.07:57
dcalisteThat's why, I think the user reporting MRs are important to go with the CalDAV failure-hardening one.07:58
flypigYes, that makes sense.07:59
dcalisteThe remaining downside, is that for non network failures, the user will have no way to solve the problem (like it is now, but eh).07:59
chriadamat least they know, and can check manually.07:59
dcalisteExact, and if we can store in a way in the Buteo log the error reason, we may even get bug reports without having to run the msyncd daemon in debug mode and try to reproduce.08:00
dcalisteBecause all non-network failures are programmatic ones, malformed iCal, unexpected server responses…08:01
dcalisteBut i actually requires some modifications in the Buteo sync-logging mechanism. If you think it's a good direction to go, I can work on a proposal.08:02
flypigIt sounds very sensible to have the specific error info logged in these cases.08:03
chriadamfine-grained buteo error logging is definitely something I would like.  but I haven't given any thought to the specifics, and we haven't committed any resources to actually implementing the appropriate UI / flows to allow the user to deal with such, and not sure when that will get roadmapped.  but yes, it certainly would be valuable.08:05
chriadamwhen I poke people about this internally, the response is usually "I agree, but no resources for it currently" basically.08:05
chriadambut also would need to check if any changes would require modifications to things like sailfish-eas which is internal, etc08:06
chriadamaside from our open sourced social plugins / carddav+caldav / etc.08:06
dcalisteOk, if you agree internally to have it, it's already fine. I'll see how to add a per-item log info in the SyncLog structure and XML serialisation. Like that, we can store incoming faulty iCal, detailed network error when pushing a specific local modification, or deletion…08:07
flypigIt'd be great to have a centralised error list, like the Transfers list, rather than each app having to report errors in their own way, or uses having to access logs. But that's a separate issue.08:07
dcalisteI think, it's not impacting other sync plugins in fact. It would be additional possibilities to be used or not to store logging data.08:07
dcalisteflypig, I agree, but at the moment, the simplest way is to extend the SyncLog structure in Buteo alone I think.08:08
dcalisteThat being said, if you want to brainstorm once on a more global way of doing this, ping me ;)08:08
flypigYes, let's hope that happens, but as a separate thing to look at later.08:09
dcalisteButeo is already a nice centralized daemon for all most of the network sync-related things : emails, calendars, contacts, pictures… and it is already logging each sync process, storing for the last 5 sync sessions the number of exchanged items.08:11
dcalisteThe idea would be to extend it to store per item information.08:12
dcalisteIf properly designed, it could be used to know which item have been added or modified and when.08:12
dcalisteWhich could be a usefull information to have also, like "there are three new agenda addition from last sync, tap here to look at them".08:13
flypigI'm not so familiar with buteo, but that does sound like it has potential.08:14
chriadamI had nothing else to discuss - did either of you have more topics today?08:17
flypigI'll do my best to take a look at the three volatile PRs. Thanks for the useful background, but that's all from me.08:18
dcalisteNo, it's ok. My targets is to try to add unittests in my failure branch and promote it as a MR, and work on this Buteo logging mechanism per item.08:18
chriadamsounds good.  thank you very much for your efforts, and your patience.08:19
chriadamhave a great week!08:19
dcalisteThanks, both of you too.08:19
flypigSame from me.08:19
ipposkvark sir trying to sailcast on a firefox browser under linux.not quite sure if i got it right . i just usb connected phone to pc and setes developer mode and then hit start on the app . trying to open the provided url. firefox says cant connect and app says connected streaming . any ideas?19:24
projectmoonoecho echo echo19:55
*** SpeedEvil is now known as Guest1901020:31
*** BitEvil is now known as SpeedEvil20:33
*** Sellerie0 is now known as Sellerie23:04

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