tfaour
644fdefa66
New third mode alongside photos/calendar: fetches a .whiteboard file over plain WebDAV (Basic auth -- generic, not Nextcloud-specific) and renders it via a small Node.js sidecar using Excalidraw's own real export code (@excalidraw/utils + @resvg/resvg-js, no headless browser), since a .whiteboard file turns out to be Excalidraw scene JSON, not an image. The sidecar runs as a second process inside this same container (Dockerfile installs Node, start.sh backgrounds it before exec'ing uvicorn) rather than a separate docker-compose service -- lightweight, stateless, reachable only at 127.0.0.1 from the Python process, nothing worth independently scaling. The rendered PNG is treated exactly like a photo from there on -- composed/quantized through the existing image_pipeline (letterboxed, never cropped) rather than a second parallel rendering pipeline. WebDAV credentials support the common "it's actually the same Nextcloud account as my CalDAV" case (an explicit opt-in checkbox, not silently inferred) while still working with any WebDAV server generically. Frame-level source (URL + owning account) follows the same owner- controls-their-own-data permission split as calendar sources and the week view's task list: only the account owner can point a frame at it, anyone linked can clear it. Honest limitation: this environment has no Node.js/npm, so render-service/ is written carefully against each library's documented API (verified via the npm registry, including transitive dependency licenses after the CalDAV/AGPL surprise earlier this session) but has never actually been executed. First real docker build is the first true test -- see render-service/README.md.
whiteboard-render
Local sidecar for whiteboard frame mode -- see server.js's own header
comment for the full "why Node, why not a headless browser" reasoning.
Not an independently deployed service: it runs as a second process
inside the main server's container (../Dockerfile installs Node,
../start.sh launches this in the background before exec-ing
uvicorn), reachable only at 127.0.0.1:3001 from the Python process in
that same container.
Not runtime-tested against a real npm install during development
-- this environment had no Node.js/npm available, only the npm registry
API (used to verify the dependency versions/licenses in package.json
actually exist and resolve). The code is written carefully against each
library's documented API (@excalidraw/utils's exportToSvg,
@resvg/resvg-js's Resvg class), but the first real build
(docker compose build) is the first time this has actually executed
end to end. If something's off, docker compose logs will show it --
most likely candidates are exportToSvg's actual return type (string vs.
DOM element -- handled defensively, see server.js) or a font-rendering
quirk, not a wrong API shape.
Local development (if you have Node 20.19+/22.13+ installed)
cd render-service
npm install
npm start # listens on 127.0.0.1:3001
curl -X POST http://127.0.0.1:3001/render \
-H "Content-Type: application/json" \
-d '{"elements": [], "width": 800}' \
-o /tmp/test.png # an empty scene -- just checks the service comes up and returns a valid PNG