| Age | Commit message (Collapse) | Author |
|---|
|
pim/invite makes an event and, when it names attendees, sends the
invitation -- which on a caldav server with auto-schedule is the same
act. -p writes the object to standard output instead, so it can go to
upas/marshal as iMIP, into a directory an ical/fs is serving, or
nowhere in particular. There is no separate verb for inviting because
to a calendar there is no separate thing.
It writes the tree's own key: value form rather than icalendar. The
first version spelled SUMMARY: by hand and got "lunch, then a walk"
wrong: a comma is a separator there and wants escaping. Parsing with
go-ical and generating by hand is the wrong asymmetry, so calfs grew
Compose, and now the same shape the tree emits is the shape it accepts.
The one UID we ever mint -- as organiser we own the event -- is minted
there too.
pim/invites lists what is waiting for an answer, which is what makes
pim/rsvp usable: it walks the date tree rather than every event, since
an invitation you never answered last March is not news.
agenda and show take -d date now, via seconds(1), which parses a human
date where date(1) only formats one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
|
caldav/fs is the second backend, and it cost ~330 lines: discovery,
a report for the window, ETags to decide whether anything moved. The
event model, recurrence expansion, the tree, ctl, query, alarm and
changed all came from lib/cal untouched, which is what the split was
for. go-webdav hands back *ical.Calendar from the same library lib/cal
parses with, so FromCalendars takes it straight in.
Two interfaces, both optional. Identity says whose calendar this is,
because in iTIP your identity is the mailto: in your own ATTENDEE line
and nothing else can tell which attendee is you. RSVPer says the
backend can answer an invitation -- meaning both halves of it, updating
your copy and telling the organiser. A backend that can only do one
should not implement it, so partstat is 0444 on a published .ics and
writing to it fails rather than half-working.
Two bugs worth naming. go-webdav resolves paths with path.Join, which
drops a trailing slash: pointed at /dav/ it asks about /dav, and Cyrus
answers 405 for that spelling and 207 for the other, so the first
PROPFIND is done by hand. And an absolute DAV href replaces the
endpoint's path rather than extending it; appending gave
/dav/dav/calendars/..., a 404, and a probe reading 404 as "no" hid
calendar-auto-schedule, which fastmail does in fact offer.
pimup brings mail and the calendars up and mounts them; riostart runs
it before opening any window, since a mount only exists in the
namespace that made it. rio does not run riostart by itself: it is the
argument to -i.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
|
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>
|
