pastilhasandClaude Opus 5
8cf210eae5
step 3 of docs/nextcloud-replacement.md. collections, events and contacts as plain json, so the browser never has to parse multistatus xml to draw a list. this talks dav to radicale over loopback rather than reading its on-disk format. the storage layout is radicale's private business and changes between versions; propfind is its supported interface and costs one in-process hop. parsing the storage directly would be faster and would break silently on upgrade, which is a bad trade for a calendar. three bugs found and fixed while verifying, all of which fail quietly rather than loudly: calendar-data and address-data are NOT webdav live properties. rfc 4791 and 6352 define them as report-only, and radicale correctly returns an empty prop for them under propfind — so the first version returned a 207 full of nothing, which reads exactly like "your calendar is empty". the principal resource matched the calendar test, because `<C:calendar-home-set/>` satisfies /calendar\b/. the principal showed up in the list as a calendar called "1". the tag has to be required to end. the internal fetcher omitted X-Script-Name, so the ui was handed /1/work/ for the same collection a phone sees as /dav/1/work/, and nothing downstream could have matched them up. ical.ts is deliberately small: it unfolds lines and pulls out the fields a list shows. it does NOT expand rrule or resolve vtimezone — radicale owns correctness there, and rrule is passed through raw so the ui can say "repeats" without either of us pretending to know when. verified against the running stack with a real vevent and a real vcard, then the fixtures were removed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>