‹ back home

Specification and development status for valarmd

2023-11-30 #calendar #open-source #plan

I have made a few mentions to valarmd, a project of mine which is paused for the moment. It is a daemon used to show desktop notifications for alarms in calendar entries. This is its specification. I hope to continue working on it after completing my current work on vdirsyncer.

Specification for valarmd

The basic usage is:

valarmd --socket /path/to/socket --vdir /path/to/vdir

valarmd shall read icalendar components (both events and todos) from a local file-system directory, extracting their respective dates, alarms and summaries. It will also monitor the directory for any changes to these files and load any changes.

At the time of each alarm, valarmd will write a single event into its socket. An event is a JSON object, encoded into a single line:

{"summary": "Meeting with Alice", "alarm": 1700811229, "type": "event", "start": 1700813029}

Programs that read events from this socket can perform all kind of actions:

Clearly, anything can be done with the information. How these alarms are presented is up to end users.

Development status

The current work in progress is written in Rust. Parsing icalendar timezones and recurrence rules is a bit not trivial, and existing Rust libraries have some limitations that need to be addressed:

The current (incomplete and broken) implementation is in the valarmd repository. There is also a short thread covering its status in further detail.

Given limitations of existing libraries (and being focused elsewhere), this project remains paused. A few workarounds have been mentioned, but they only work for some events in my personal calendar. Missing some alarms is not a reasonable compromise.

Considering for golang

I had considered golang before using Rust, but its timezone implementation is annoying to work with. Golang’s timezone implementation is represented by the Location type. Creating a new Location instance cannot be done directly; it can only be done by providing IANA Time Zone database-formatted data as input.

So in order to create a Location instance from an icalendar VTIMEZONE, it needs to be converted into IANA Time Zone database-format first, and then into Location.

This is an awful API (which won’t be fixed), and only a single example. In general, I don’t consider golang’s datetime and timezone interfaces flexible enough for tools that need to interoperate with icalendar data.

See also

Have comments or want to discuss this topic?
Send an email to ~whynothugo/public-inbox@lists.sr.ht (mailing list etiquette)

— § —