Say Only That It Changed — Why the Value Must Not Ride Along

Through part 5, a screen wanting the latest value had to ask — every second, or when a person refreshed.

Tell it

One line after changing the value.

waiting -= n;
_save(waiting);
// Say that it changed. Not what it changed to.
server.notifyResourceUpdated('desk://waiting');

Add a subscribable resource and turn subscribe: true on.

resources: ResourcesCapability(listChanged: true, subscribe: true),

What goes on the wire

{"jsonrpc":"2.0","method":"notifications/resources/updated","params":{"uri":"desk://waiting"}}

Only the uri. How many are waiting is not in it.

Why the value must not ride along

Putting the value in looks obvious — one round trip instead of two. But notifications guarantee no ordering.

server: waiting becomes 2 → notification A sent
server: waiting becomes 1 → notification B sent
client: B arrives (1)  →  A arrives (2)   ← the order flipped
screen: 2

With a value attached, a late old notification overwrites a newer value. The screen quietly shows the wrong number and nobody knows.

Send only "it changed" and the problem disappears. However many arrive, in whatever order, the receiver reads and gets the latest at that moment.

The kitchen screen piece reached the same conclusion. There it was a design choice; here the package only sends it that way — notifyResourceUpdated(uri) has no slot for a value.

Nothing goes out without a subscription

Caught while building. notifyResourceUpdated was called, the server logged it, and nothing appeared on the wire.

notified desk://waiting        ← the server did call it
(nothing on the client side)

Because it is not sent to clients that did not subscribe. That is the spec.

{"jsonrpc":"2.0","id":2,"method":"resources/subscribe","params":{"uri":"desk://waiting"}}

After that it arrives. An easy place to mistake for a server defect — the server was right, the receiver had not asked.