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, 44 insertions, 0 deletions

diff --git a/pim/doc/todo.md b/pim/doc/todo.md
new file mode 100644
index 0000000..1e34157
--- /dev/null
+++ b/pim/doc/todo.md
@@ -0,0 +1,44 @@
+# ical/fs todo
+
+## Next
+
+- **rsvp**. `partstat` is not yet in the tree. It should be writable, and
+  the write should be the whole user interface: `echo ACCEPTED
+  >/mnt/pim/events/uuid/<uid>/partstat`. Transport stays inside the server --
+  iMIP mail via `upas/marshal` for the ics backend, a JMAP method call
+  for `jmap/fs`. `pim/rsvp` writes the file and knows nothing else.
+- **plumb port for alarms**, following `seemail`. The blocking `alarm`
+  file is one-to-one; a plumb port gives fan-out so `pim/alertcat`, a
+  bell and a logger can all see the same alarm.
+- **`pim/next`** -- print the next event, one line, for a window label.
+- **the slug is lossy**. `Go Home LTD & Kissinger -> API` becomes
+  `Go-Home-LTD-_-Kissinger--_-API`; every non-alphanumeric collapses to
+  `_`, so names are ugly and not reversible. The summary is intact inside
+  the file, but the filename could be kinder.
+- **`pim/free`** -- free/busy over a range.
+- **plumb rules** -- click a date, `agenda` opens that day.
+
+## Backends
+
+- `jmap/fs` against Fastmail. JSCalendar is JSON, so no parser; the work
+  is OAuth2 and the method surface. No Go library implements JMAP
+  calendars -- `rockorager/go-jmap` is core+mail only.
+- `caldav/fs` via `emersion/go-webdav`. Untested on plan9, but its
+  transport is `net/http`, which is verified working.
+
+## Known gaps
+
+- Absolute VALARM triggers (`TRIGGER;VALUE=DATE-TIME`) are ignored; only
+  relative ones fire. `RELATED=END`, `DURATION`+`REPEAT` unhandled.
+  Note Google's `basic.ics` exports **no VALARM at all**, so alarms need a
+  backend that carries them.
+- Embedded `VTIMEZONE` definitions are ignored. `TZID=` is resolved by
+  IANA name through Go's `time/tzdata` instead, which is correct for
+  Google (`America/New_York`) but will fail on a server that emits
+  Windows-style zone names or a zone not in the IANA database.
+- Only `STATUS:CANCELLED` cancels an occurrence. `METHOD:CANCEL` is not
+  handled.
+- The whole tree is rebuilt on refresh. Fine at this size, not forever.
+- Directory listing order from go9p is non-deterministic (it iterates a
+  map to build the child list). `ls` sorts, so it does not show, but do
+  not depend on order.