Story: Wt and HTTP introduction
Table of Contents
This page documents a story in Sprint 07. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
Goal
Introduce a second presentation tier — Wt for the web frontend and an HTTP entry point on comms — without porting the domain to another language.
Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 07 |
| Now | Completed 2025-12-30. |
| Waiting on | None. |
| Next | None. |
| Last touched | 2025-12-30 |
Continued in: Wt and HTTP review (sprint 08) — validation of the Wt application + HTTP service introduced here.
Acceptance
- Wt scaffolded in via vcpkg; minimal page lists currencies.
- HTTP endpoint with at least one read and one write path, sharing handlers with the socket path.
- Build green; both surfaces tested.
Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Setup basic Wt infrastructure | DONE | 2026-05-19 | 2025-12-29 | Pull Wt in as a peer-of-Qt UI toolkit so the same service can drive a web frontend. |
| Consider exposing endpoints via HTTP | DONE | 2026-05-19 | 2025-12-30 | Add an HTTP entry point on the comms layer so non-Qt clients can talk to the service. |
Decisions
- Wt over a JS frontend
- lets us share the same C++ domain types between desktop and web; one source of truth.
- HTTP reuses socket handlers
- enabled by the type-traits dispatch from the comms story; otherwise we'd have two copies of every handler.
Out of scope
- A full-blown Wt UI; this story just proves the wiring.
See also
- Comms features — supplies the type-traits dispatch the HTTP path reuses.