Open design questions

[el-bri-ga]

These are the questions the design leaves open. Each has an issue for the eventual decision. This thread is for thinking out loud before then.

Already filed

• Several inputs per workload (Design: workloads with several inputs #25). Joins need it, but reading streams in arrival order breaks determinism. Should the merge order be its own record? Should a separate "merger" workload produce it?
• Where placement lives (Design: where placement decisions live #26). In the agents as rules, or in a scheduler that is itself a felixd workload writing assignments, which would make scheduling replayable too?
• Effects (Design: effects after felixd #27). How should a workload reach HTTP, files or a clock without breaking replay? Full WASI with every response recorded, or a narrow set of host calls?

Not filed yet

• The workload interface. A WIT world with step, snapshot, restore and inspect, as the design has now, or something simpler, such as a raw ABI or one-record-in, records-out over stdin and stdout?
• Workload languages. Rust first, certainly. Which next: TinyGo, componentize-py, JavaScript?
• Snapshot compatibility across module versions. How does a new version declare that it can read an old snapshot? This ties in with Check an upgrade against recorded inputs #29.
• Lease TTL. The default is 10 s. That's slow for a demo, while a shorter TTL risks false failovers on a busy node. What should it be?
• Grants per workload. In v0 any node can write any workload's output. When does that need to change?

Pick any one and argue for an answer.