For some resources (e.g. user/.../input or a potential notification system in the future) persisting the most recent value is generally undesirable and can manifest itself in weird behavior (e.g. a stale keyboard input from some old client being sent to a newly opened STREAM). The immediate fix for this is client-sided (see ProjectLighthouseCAU/lighthouse-rust@fb750a3), it would be cool to have centralized solution for this though to avoid having to implement this in every client.
Some ideas:
- Add a way in beacon to declare a resource as "passthrough" (i.e. to not persist its values and only forward
PUTs to active streams). A GET should potentially error in that case and STREAM should either not respond until the first update (of the streamed resource) arrives or not return a payload.
- Add a meta flag to
PUT that avoids updating the resource and "only" forwards the update to the resource. This would potentially be the least invasive/most backwards-compatible solution.
- Alternatively add a new method for this (
DISPATCH/NOTIFY/SEND/PUBLISH/...)
For some resources (e.g.
user/.../inputor a potential notification system in the future) persisting the most recent value is generally undesirable and can manifest itself in weird behavior (e.g. a stale keyboard input from some old client being sent to a newly openedSTREAM). The immediate fix for this is client-sided (see ProjectLighthouseCAU/lighthouse-rust@fb750a3), it would be cool to have centralized solution for this though to avoid having to implement this in every client.Some ideas:
PUTs to active streams). AGETshould potentially error in that case andSTREAMshould either not respond until the first update (of the streamed resource) arrives or not return a payload.PUTthat avoids updating the resource and "only" forwards the update to the resource. This would potentially be the least invasive/most backwards-compatible solution.DISPATCH/NOTIFY/SEND/PUBLISH/...)