1.5 KiB
1.5 KiB
Central print service routing to networked label printers
Status: accepted
Cards reach board printers through a small internal print service: the CLI renders client-side, then POSTs the card image + board-id to the service, which forwards the raster to that board's networked Brother QL-1110NWB by IP. We chose this over direct CLI→printer and over corporate CUPS queues because at 50+ boards the dominant cost is operational — a board→printer registry, retries, and "did it print / is it out of labels" visibility — which a central router provides and 50 hand-configured connections do not (serves G2/F4).
Considered options
- Direct-to-printer (T-A). No server, but 50 addresses to track, cross-floor reachability issues, and no central status.
- Central service (T-B, chosen). One registry +
--boardrouting + status; also the future home of the F5 short-link redirector. - Corporate CUPS (T-C). Reuses IT ops, but label media/routing is awkward in generic queues and couples the project to IT's roadmap.
Consequences
- The service is a single point of failure: if it is down, printing stalls. Mitigation (watched, not built for v1): keep it simple/HA and let the CLI cache the registry to fall back to direct-print.
- Printers must be networked (QL-1110NWB) rather than USB-only — slightly pricier per unit, but avoids a Raspberry Pi agent (and its patching burden) on every board.
- Rendering stays client-side; the service is a thin router, not a renderer.