Expand description
What everybody is doing now — the roster awareness(f) reads.
crate::presence holds who is connected; this holds what each of them contributes. The two
are separate registries because they move at different rates and for different reasons: a
connection joins and leaves, and between those two moments a client may change its
contribution any number of times by navigating.
The compiler’s half is a source in the signal graph ([beck_core::signal::Op::Awareness]) and a
role beside the view ([beck_core::split::Roles::awareness]). The role is a function
Session -> T; this is what applies it, once per connection per change, because the
subscribers are the runtime’s fact and not the graph’s — the signal graph of one program has no
way to name another connection’s session.
§Everything here follows from presence’s one sentence
Nothing is appended, snapshotted or replayed; a process that restarts comes back empty; the
checker keeps awareness away from the chokepoint (B0515) so no event’s existence depended on
it. The bound is crate::presence’s bound for crate::presence’s reason — the table is
keyed by a string the client may choose (docs/82
§82.5) — and past Config::capacity distinct actors a new one is not recorded, so the
roster under-reports rather than growing.
§What is different: a value, and therefore a size
A roster of counts is bounded by its capacity alone. A roster of values is bounded by the
capacity times whatever f returns, and f is the program’s — a session’s path is a few
dozen bytes, and nothing in the type system says it has to be. Config::each is the second
bound this needs and presence does not: a contribution whose rendered size exceeds it is
refused, the actor keeps whatever it contributed before, and Registry::oversized counts
it. Refusing one client’s update is the failure this direction should have, and holding an
unbounded value per connection is not.