pim: personal information management, starting with a calendar

A calendar as a file tree, and tools that only know the tree:

	events/date/yyyy/mm/dd/hhmm-summary	as lived
	events/uuid/<uid>/			as stored
	ctl query alarm changed

lib/cal owns all of that. A backend supplies events and, where its
protocol allows, takes changes back -- six methods. cmd/icalfs is the
first: it reads .ics files from a directory and nothing else, because
fetching is rc/fetch's job and hget already exists. That keeps
net/http out of the binary and makes a subscribed calendar and a local
one the same thing.

The tools are rc on purpose. If the tree needs a compiled program to be
useful, the tree is the wrong shape. Three things were added to the
tree because the rc port needed them: a path from an occurrence to its
event, epoch seconds beside RFC3339, and a numeric slot for all-day
events so test(1) can compare it.

ctl reports caps, so a tool can say "read only" instead of trying and
failing. A published .ics is read only: nowhere to PUT, and no
METHOD:REQUEST to reply to. CalDAV would be read write rsvp schedule,
and that is the next backend.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1 files changed, 22 insertions, 0 deletions

diff --git a/pim/mk.sh b/pim/mk.sh
new file mode 100755
index 0000000..e86c17c
--- /dev/null
+++ b/pim/mk.sh
@@ -0,0 +1,22 @@
+#!/bin/sh
+# Cross-compile the calendar file servers for 9front.
+#
+# One library, one binary per protocol. They install as ical/fs,
+# caldav/fs and so on -- named for the protocol they speak, because a
+# backend is a protocol and protocols span data types.
+#
+# Go 1.24.x is broken on plan9/amd64 (spinbit mutex panic before main),
+# so pin a known-good toolchain.
+set -e
+: ${GOTOOLCHAIN:=go1.27.0}
+: ${GOOS:=plan9}
+: ${GOARCH:=amd64}
+export GOTOOLCHAIN GOOS GOARCH
+
+cd "$(dirname "$0")"
+mkdir -p bin
+for c in cmd/*; do
+	n=$(basename "$c")
+	go build -o "bin/$n" "./$c"
+done
+ls -l bin