871fc7c8de
This protocol involves far too much accidental complexity. The original motivating use-case was to provide a convenient way to send arbitrary data to layout clients at runtime in order to avoid layout clients needing to implement their own IPC and do this over a side-channel. Instead of implementing a quite complex but still rigid options protocol and storing this state in the compositor, instead we will simply add events to the layout protocol to support this use case. Consider the status quo event sequence: 1. send get_option_handle request (riverctl) 2. roundtrip waiting for first event (riverctl) 3. send set_foo_value request (riverctl) 4. receive set_foo_value request (river) 5. send foo_value event to all current handles (river) 6. receive foo_value event (rivertile) 7. send parameters_changed request (rivertile) 8. receive parameters_changed request (river) 9. send layout_demand (river) And compare with the event sequence after the proposed change: 1. send set_foo_value request (riverctl) 2. receive set_foo_value request (river) 3. send set_foo_value event (river) 4. send layout_demand (river) This requires *much* less back and forth between the server and clients and is clearly much simpler. |
||
|---|---|---|
| .. | ||
| init | ||
| status.zig | ||