Pimsync “owner of calendar” metadata

[permalink]

Pimsync synchronises a few metadata attributes for calendars (displayname, colour, description, order). I had an intent to add owner to this list. This turns out to be impractical.

A WebDAV server exposes a calendar-user-address-set property, which is the address (typically an email) of a user. This property would represent the owner for a calendar. I planned to synchronise this property for every calendar, so that applications inspecting a calendars on a local directory can understand the owner of each one. If one of my calendars belongs to hugo@whynothugo.nl, and another to hugo@example.com, applications would be able to automatically detect this information and use it for sending out invites (via iTIP) with the correct Organiser or for sending RSVPs with the correct Attendant.

I overlooked one important detail. The calendar-user-address-set property is not defined for each calendar; it’s defined for the “user principal”, a collection which contains multiple calendars, typically all the calendars belonging to a single user. Due to this detail there are too many cases where the results of synchronising it would be unexpected, if not outright invalid.

Example 1: I share my work calendar with a colleague, and they synchronise it into their server. The “owner” property is not per-calendar, but at one level up. Synchronising the owner would change the owner for all their personal calendars, which would trickle into all sorts of issues. The only solution is to ignore the owner in this case.

Example 2: I synchronise collections from two different CalDAV sources into a single local vdir. The two CalDAV sources have a different owner. There is no way to synchronise the two conflicting values into the local storage.

Finally, pimsync’s approach to storages and collections is that collections (e.g.: calendars or address books) have properties, not the whole storage. The minimal unit which we synchronise is a collection, and having properties at a higher level simply doesn’t fit the model.

I can’t think of an approach for this feature which doesn’t produce undesirable results in surprising ways. So I’ve decided to omit this feature, the alternative would be to surprise users in how their data is overwritten. By the way, changing the calendar-user-address-set on the server would also impact how the server processes replies, and I can imagine someone going crazy trying to understand the source of the bug until the pinpoint it back to pimsync.

Other components of the project do implement related functionality. libdav provides a function to obtain the current calendar address set, and davcli exposes this information when inspecting a server. Both of these features shall remain in place.

Tracking issue: https://todo.sr.ht/~whynothugo/pimsync/8

Pimsync “shell” mechanism

[permalink]

vdirsyncer allowed specifying a short in-line shell script for retrieving credentials. I’ve implemented this same mechanism in pimsync. It’s really just a shortcut, but it makes lives easier for people, and the implementation cost is minimal.

You can now specify that credentials are to be retrieved via a command:

# This is safe to use with any special character.
password {
    cmd hiq -dFpassword proto=carddavs username=…
}

Or via a short sh snippet:

# Shell rules apply for special characters here, but you can pipe much easier
password {
    shell pass show communication/migadu.com | head -1
}

In reality, the latter is an alias for the following, which is a bit less comprehensible for non-hardcore shell users:

password {
    cmd sh -c "pass show communication/migadu.com | head -1"
}

Tracking issue: https://todo.sr.ht/~whynothugo/pimsync/136

Pimsync v0.3.0

[permalink]

I’ve tagged a new release with the above features a few other bugfixes. See the changelog for details.

Roadmap

[permalink]

I’ve tagged prioritised tasks in the issue tracker as todo. This is mostly for my own visibility, and these fall under the current grant from NLNet.

I had a list of tasks that fell under the scope of the grant, but each time that I needed to prioritise tasks, I needed to cross-check that list with the issue tracker, which ended up in a lot of pointless overhear. Tagging all issues is the obvious solution in hindsight.