09:01:12 <chriadam_> #startmeeting Sailfish OS CalDAV/CardDAV Contributors Meeting
09:01:12 <merbot> Meeting started Mon Jul  3 09:01:12 2017 UTC.  The chair is chriadam_. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
09:01:12 <merbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
09:01:30 <chriadam_> The agenda for today's meeting can be found at:
09:01:33 <chriadam_> #link https://sailfishos.org/wiki/CalDAV_and_CardDAV_Community_Contributions#03.2F07.2F2017_Meeting
09:01:41 <chriadam_> #topic Introductions
09:01:50 <chriadam_> Please introduce yourself with #info nick/name
09:02:02 <chriadam_> #info Chris Adams, developer at Jolla
09:02:16 <dcaliste> #info Damien Caliste, community
09:02:34 <chriadam_> hi dcaliste!  glad you could make it!
09:02:50 <chriadam_> we'll wait a few more minutes in case people are late, then get started on the rest of the agenda.
09:02:53 <dcaliste> Hello chriadam_, yes, this time no public holiday in France ;)
09:03:13 <chriadam_> dcaliste: btw we need to talk with abranson about the QMF PRs you have
09:03:52 <dcaliste> Good, good, yes I have time this morning, that would be great.
09:03:55 <abranson> yes this is as good a place as any. thanks for the mention
09:04:05 <chriadam_> I spoke to mvogt and he is happy for them to go in, but isn't able to spend time merging / supporting them going forward.  My understanding is that Pekka and Andrew are willing to help in that regard.
09:04:27 <chriadam_> Anyway let's discuss that directly after this meeting, if that suits you both?
09:04:34 <abranson> yep!
09:04:36 <dcaliste> Yep for me
09:04:38 <chriadam_> great
09:05:01 <chriadam_> will wait a couple more minutes for latecomers, then will get started
09:05:33 * LarstiQ lurks as always
09:06:19 <chriadam_> hi LarstiQ
09:06:31 <chriadam_> hi ljo_
09:06:49 <ljo_> hi, sorry for being late
09:06:56 <chriadam_> no worries :-)
09:07:08 <chriadam_> waiting another minute or so then we'll get started on the agenda proper
09:08:29 <chriadam_> ok, let's continue:
09:08:37 <chriadam_> #topic Follow-up items from last meeting
09:09:27 <chriadam_> Biggest issue to follow up on is the JB#38601 testing - I posted to TJC and asked for community help in testing the new CalDAV package.  While it doesn't resolve all of the issues which have been reported, it does fix the calendar duplication issue for most people who tested it
09:09:54 <chriadam_> as such, unless someone here has an objection, I will merge the PR as it currently stands
09:10:00 <chriadam_> (and try to get it into 2.1.1 but we'll see...)
09:10:11 <dcaliste> I wanted to write a small shell script exporting non-private data from the calendar data-base.
09:10:21 <dcaliste> Like UID and so on.
09:10:23 <ljo_> please go ahead
09:10:25 <abranson> I haven't seen the duplication again since we last spoke, so I don't have anything to chase
09:10:57 <dcaliste> So like that reporters can send the content of there local database for us to understand what can cause duplication.
09:11:03 <chriadam_> dcaliste: makes sense
09:11:04 <ljo_> Only got one since you published the latest test build.
09:11:04 <dcaliste> Do you think it can help ?
09:11:37 <chriadam_> dcaliste: I think it could help.  Instead of separate shell script, I would prefer the functionality got added either to icalconverter (from nemo-qml-plugin-calendar-tools) or the new cdavtool from carddav repo
09:12:01 <chriadam_> but a shell script (which people can copy/paste and run from the wiki) would also be useful
09:12:32 <dcaliste> chriadam_: ok for the C tool. A C script with a sqlite command can be quite simple also.
09:12:41 <chriadam_> ljo_: so you still have seen a duplication with that new package?  I think abranson saw one also, but not able to reproduce reliably.  I guess there is an edge case which can still be triggered, but it is an improvement nonetheless?
09:12:57 <dcaliste> Like that we should be able to replay locally the duplication, having the request and the database.
09:13:05 <chriadam_> right
09:13:09 <abranson> just to ask again - is there any way we can detect a caldav crash and remove the extra notebook? maybe log the current ones before it's launched, then remove any new ones created during a crashing run?
09:13:50 <ljo_> Definitely an improvement. :)
09:13:55 <chriadam_> abranson: all things are possible.  we could store a dirty flag in the cdav.ini file under privileged/Sync/ dir
09:13:55 <abranson> i understand that the duplication happens because caldav always creates a new notebook with the remote calendar data locally for comparison, but usually cleans it up after sync if it's not crashed
09:14:39 <abranson> I suppose in that case people would see their calendars go stale instead of duplicate
09:14:49 <chriadam_> abranson: but that is in some respects a possible cause of problems (e.g., if the flag isn't cleared appropriately (perhaps due to a crash...) then we could delete the notebook even after the cycle completes successfully)
09:15:19 <chriadam_> but yes, I think the chance of a crash in reading/writing a .ini is far less likely than a crash in network / calendar event manipulation code
09:15:57 <chriadam_> abranson: I'll put it on the TODO list
09:16:15 <chriadam_> any other items to follow up on since the last meeting?
09:16:17 <dcaliste> And I may add about this, that this temporary notebook should be clean anyway. So if ini file contains a flag and the notebook exists it should be removed, no ?
09:16:32 <abranson> we could even backup the db, then restore it if there's a crash. that would avoid even more data damage
09:17:05 <chriadam_> abranson: unlikely to work correctly, because in Sailfish OS we unfortunately don't have single-process daemons to provide eg Calendar service
09:17:20 <chriadam_> which means multiple processes can have the database open, which means sqlite will have lock files and journal files open
09:17:35 <chriadam_> copying just the .db is unlikely to be enough.  Perhaps sqlite gurus can correct me
09:17:55 <dcaliste> Or use a separate db for temporary work… Stupid idea ? Or too much modifications to be done ?
09:18:04 <abranson> does sqlite do snapshotting?
09:18:12 <chriadam_> in the hopefully not too distant future, it'd be nice if we could rewrite our middleware to transition to a daemon-service architecture.  but not today.
09:18:49 <chriadam_> dcaliste: well, it's not "temporary" per se.  The problem is that mkcal doesn't allow creating notebooks and editing events in notebooks within the same transaction (specifically, creating a notebook causes a transaction commit)
09:19:09 <chriadam_> abranson: hrm, perhaps it does.  actually, I'd be surprised if it didn't.  Hopefully it is concurrence-safe also... but I'd have to check.
09:19:17 <abranson> it's experimental: https://www.sqlite.org/c3ref/snapshot_get.html
09:19:32 <chriadam_> hrm.
09:20:02 <chriadam_> something to look into, perhaps.  in the near future, a dirty flag in the caldav.ini is probably simpler.  but let's investigate.
09:20:14 <chriadam_> ok, continuing to next agenda item:
09:20:17 <chriadam_> #topic JB#38601 - CalDAV plugin fails during sync of some "broken" events, resulting in duplications
09:20:26 <chriadam_> Basically, this is just: should I merge that PR now?
09:20:34 <chriadam_> from previous discussion I guess the answer is "yes"
09:20:38 <chriadam_> at least no-one seemed to disagree ;-)
09:20:47 <chriadam_> so, moving on to next topic:
09:20:56 <chriadam_> oh, before I move on
09:20:58 <chriadam_> #link https://git.merproject.org/mer-core/buteo-sync-plugin-caldav/merge_requests/20/diffs
09:21:05 <chriadam_> more reviewers welcome of course
09:21:14 <chriadam_> #topic MER#1796 - local modification being reported erroneously to calendar events
09:21:37 <chriadam_> Ok, next topic is: reported from a couple of people that repeated sync cycles with no changes either remotely or locally, result in a single local event being reported as modified
09:21:42 <chriadam_> and upsynced due to that detection
09:21:51 <chriadam_> I have been provided a sync log which clearly shows this issue
09:21:58 <chriadam_> but I haven't yet had the chance to investigate why
09:22:24 <chriadam_> (most likely I'll have to generate a custom package which provides more debug output, specifying precisely which field is comparing as different)
09:22:44 <chriadam_> has anyone seen this with their own calendar / sync cycles?
09:23:02 <chriadam_> is anyone willing to investigate this one?  if not, I will try to investigate some time in the next couple of weeks.
09:23:06 <abranson> no, haven't seen a server duplication of an event for years!
09:23:15 <chriadam_> it's not a duplication
09:23:21 <chriadam_> it's a spurious local modification
09:23:40 <chriadam_> e.g., the local plugin looks at the local data and says "this event has changed since the last time I upsynced to the server!  I'd better upsync it"
09:23:49 <chriadam_> and the upsync works (basically a null-update)
09:24:05 <chriadam_> but it happens on every single sync cycle (generating needless data usage, basically, although very small amount)
09:24:21 <chriadam_> my gut feeling is that it might be related to the "alarms" / "reminders"
09:24:36 <chriadam_> but it might be something else altogether
09:25:03 <chriadam_> ok, I will try to investigate that, over the next couple of weeks :-)
09:25:12 <chriadam_> #topic MER#1714 - isdn field added to phone numbers on upsync (investigation required)
09:25:33 <chriadam_> This is still outstanding, seems like QtVersit prefers ISDN type for phone numbers which don't have a specific subtype set
09:25:57 <chriadam_> If anyone wants to take this, they are more than welcome.  I won't have time to investigate this issue for a while.
09:26:12 <chriadam_> #topic MER#1751 - main issue resolved, but some minor tasks here remain (.eml suffixes)
09:26:27 <chriadam_> Another good task for a new contributor: it seems Kerio servers can store contacts with .eml suffix instead of .vcf
09:26:45 <chriadam_> Should be relatively simple to inspect the resource, determine if it's reported type is Contact, and if so, sync it
09:27:09 <chriadam_> Again, I don't have time to look into this one, so if anyone wants to take it, that'd be cool.  Low priority but good intro task I think.
09:27:19 <chriadam_> #topic Any other business?
09:27:27 <chriadam_> dcaliste: was there anything in particular you wanted to raise?
09:27:53 <dcaliste> No, sorry, didn't add much time recently about CalDAV…
09:28:09 <chriadam_> no worries at all :-)  you've done a huge amount
09:28:13 <dcaliste> s/add/have/…
09:28:29 <chriadam_> ljo_: abranson: anything?
09:29:05 <ljo_> nope, will be away in us for work 5 weeks,  so not much time either.
09:30:15 <chriadam_> all good :-)
09:30:24 <chriadam_> ok, that's all I had, so closing meeting in 3...
09:30:32 <chriadam_> 2...
09:30:39 <ljo_> i will try to trigger the duplication though.
09:30:54 <chriadam_> yep, that'd definitely be useful, thanks
09:30:58 <chriadam_> 1...
09:31:05 <chriadam_> #endmeeting