| *** frinring_ is now known as frinring | 01:18 | |
| *** zbenjamin is now known as Guest46362 | 01:47 | |
| *** zbenjamin_ is now known as zbenjamin | 01:47 | |
| dcaliste | Hello chriadam, how are you ? | 07:17 |
|---|---|---|
| chriadam | hi dcaliste | 07:17 |
| chriadam | I'm well thanks | 07:17 |
| chriadam | how are you? | 07:17 |
| dcaliste | I'm fine thank you. | 07:18 |
| chriadam | that's good | 07:18 |
| chriadam | did you get my email earlier? I have had no chance to review the PRs yet unfortunately :-( | 07:18 |
| chriadam | I have poked jpetrell and pvuorela about those in a meeting just earlier today, however | 07:18 |
| dcaliste | Yes, no problem, thanks for asking to them also. | 07:19 |
| chriadam | thank you for your patience | 07:19 |
| chriadam | it has been 3 weeks and I have not progressed those :-( | 07:20 |
| dcaliste | I 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 |
| chriadam | ah excellent! | 07:20 |
| chriadam | that is good news | 07:20 |
| dcaliste | Yes, 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 |
| chriadam | nice one | 07:22 |
| dcaliste | It'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 |
| dcaliste | The 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 |
| chriadam | indeed, can ask Bree to do some more rigorous testing with different servers once we have merged the PRs, to ensure no regressions. | 07:23 |
| chriadam | yes, failure mode testing is often tricky to do, except for mockable / unit testable cases. | 07:23 |
| dcaliste | Indeed, I'm thinking of adding some unit tests to check the handler routine behaviours. But not done yet. | 07:24 |
| chriadam | :-) | 07:25 |
| dcaliste | When 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/19 | 07:26 |
| chriadam | flypig: will you have any time to look into the calendar related ones this week, by any chance? if so ^^ | 07:26 |
| dcaliste | The patch is taken from upstream, with a minor modification to ensure that mkcal is restoring properly the volatile properties. | 07:28 |
| dcaliste | I will try to have this minor modification upstreamed in the coming days. | 07:28 |
| chriadam | tyvm | 07:28 |
| flypig | Thanks 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 |
| dcaliste | I'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 |
| dcaliste | But, 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 |
| chriadam | flypig: 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 |
| dcaliste | Thank you flypig. | 07:31 |
| chriadam | flypig: so there is that PR, then one in nemo-qml-plugin-settings, then one in jolla-calendar. | 07:31 |
| chriadam | and 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 |
| dcaliste | Exact, but the QML binding is in nemo-qml-plugin-calendar ;) | 07:32 |
| flypig | Okay, that's very helpful; thanks for the explanation. | 07:32 |
| chriadam | Martin 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 |
| chriadam | oops, yes, nqpcalendar not settings | 07:32 |
| chriadam | my brain is mush ;-) | 07:32 |
| dcaliste | Basically, 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 |
| dcaliste | Then, the UI can display this out-of-sync status to the user. | 07:33 |
| dcaliste | The CalDAV plugin is modified to mark the failing events with this particular volatile properties. | 07:34 |
| chriadam | prevents 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 |
| chriadam | in 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 |
| chriadam | also pvuorela ^ | 07:37 |
| dcaliste | Yep, 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 |
| chriadam | definitely a longer-term task ;-) | 07:39 |
| flypig | chriadam, do we have a bug number for those tasks yet? | 07:39 |
| flypig | The volatile properties particularly, I mean. | 07:39 |
| chriadam | I don't recall. there was a TJC associated IIRC | 07:40 |
| flypig | Okay, I may create one then, otherwise I lose track. | 07:40 |
| flypig | I guess the actual issue is about identifying sync failures, rather than introducing volatile properties. | 07:41 |
| dcaliste | If 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/500 | 07:41 |
| dcaliste | flypig: 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 |
| dcaliste | Because it's the way they are doing it automatically upstream in KCalendarCore. | 07:42 |
| flypig | Okay, great. This'll make a nice improvement. | 07:42 |
| flypig | Thanks also for the forum link; that's helpful. | 07:42 |
| flypig | So currently if one item fails to sync, the whole calendar is dead? | 07:44 |
| dcaliste | Yes. Even worst in my opinion, if you have several calendar, a single failure somewhere stops all the process. | 07:44 |
| dcaliste | s/calendar/calendars/ | 07:44 |
| chriadam | part of dcaliste's improvements is to address this. instead, each individual failure will be marked, but the sync will continue. | 07:45 |
| chriadam | (iiuc) | 07:45 |
| dcaliste | Modifying this behaviour as chriadam is describing, implies a lot of internal changes in the CalDAV plugin though. | 07:45 |
| dcaliste | It's in my 'failure' branch at the moment. | 07:46 |
| dcaliste | https://git.sailfishos.org/dcaliste/buteo-sync-plugin-caldav/tree/failures | 07:46 |
| *** Ischwitch is now known as Ingvix | 07:47 | |
| flypig | So, 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 |
| chriadam | yes | 07:48 |
| dcaliste | They are there to expose (some of the) failures to the user. | 07:49 |
| flypig | Okay, thanks. That sounds great. | 07:49 |
| flypig | What 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 |
| dcaliste | That's a valid concern, indeed. | 07:50 |
| dcaliste | There are several possibilities: | 07:50 |
| chriadam | can 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 |
| flypig | chriadam'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 |
| chriadam | or this case | 07:54 |
| chriadam | yes | 07:54 |
| flypig | So in all those cases they'll either fix themselves on the next sync, or remain unfixable indefinitely. | 07:54 |
| flypig | No damage caused by the failed sync itself. | 07:55 |
| dcaliste | So 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 |
| flypig | Okay, I'm clear on that then. Thanks! | 07:55 |
| dcaliste | The 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 |
| dcaliste | Because now, it's simple to see that there is a problem, even without looking at the logs, nothing is syncing anymore. | 07:57 |
| dcaliste | But after the MR, many minor sync issues may pass without notice of the user because 99% of the modifications are synced alright. | 07:57 |
| dcaliste | That's why, I think the user reporting MRs are important to go with the CalDAV failure-hardening one. | 07:58 |
| flypig | Yes, that makes sense. | 07:59 |
| dcaliste | The 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 |
| chriadam | at least they know, and can check manually. | 07:59 |
| dcaliste | Exact, 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 |
| dcaliste | Because all non-network failures are programmatic ones, malformed iCal, unexpected server responses… | 08:01 |
| dcaliste | But 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 |
| flypig | It sounds very sensible to have the specific error info logged in these cases. | 08:03 |
| chriadam | fine-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 |
| chriadam | when I poke people about this internally, the response is usually "I agree, but no resources for it currently" basically. | 08:05 |
| chriadam | but also would need to check if any changes would require modifications to things like sailfish-eas which is internal, etc | 08:06 |
| chriadam | aside from our open sourced social plugins / carddav+caldav / etc. | 08:06 |
| dcaliste | Ok, 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 |
| flypig | It'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 |
| dcaliste | I 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 |
| dcaliste | flypig, I agree, but at the moment, the simplest way is to extend the SyncLog structure in Buteo alone I think. | 08:08 |
| dcaliste | That being said, if you want to brainstorm once on a more global way of doing this, ping me ;) | 08:08 |
| flypig | Yes, let's hope that happens, but as a separate thing to look at later. | 08:09 |
| chriadam | :-) | 08:10 |
| dcaliste | Buteo 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 |
| dcaliste | The idea would be to extend it to store per item information. | 08:12 |
| dcaliste | If properly designed, it could be used to know which item have been added or modified and when. | 08:12 |
| dcaliste | Which 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 |
| flypig | I'm not so familiar with buteo, but that does sound like it has potential. | 08:14 |
| chriadam | I had nothing else to discuss - did either of you have more topics today? | 08:17 |
| flypig | I'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 |
| dcaliste | No, 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 |
| chriadam | sounds good. thank you very much for your efforts, and your patience. | 08:19 |
| chriadam | have a great week! | 08:19 |
| dcaliste | Thanks, both of you too. | 08:19 |
| flypig | Same from me. | 08:19 |
| ippo | skvark 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 |
| projectmoono | echo echo echo | 19:55 |
| *** SpeedEvil is now known as Guest19010 | 20:31 | |
| *** BitEvil is now known as SpeedEvil | 20:33 | |
| *** Sellerie0 is now known as Sellerie | 23:04 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!