묻지 않는 화면 — 벽에 걸린 것은 물어서는 안 된다

문 앞의 줄 끝에 이렇게 적었다.

밀어주기(push)가 없다. 카운터가 부르면 문 앞이 따라간 건 맞지만, 그건 하니스가 두 런타임에 같은 상태를 넣어 줬기 때문이다. 이 샘플은 그걸 안 했다.

이 편이 그걸 한다.

손에 든 화면과 벽에 걸린 화면

지금까지의 샘플은 전부 물어서 알았다. 화면이 도구를 부르고, 답을 받고, 그린다.

손에 들고 있는 화면은 그래도 된다. 사람이 누르는 순간이 곧 물어볼 순간이니까.

벽에 박힌 화면은 다르다. 주방 디스플레이를 누르는 사람은 없다. 그러면 둘 중 하나가 된다.

• 계속 묻는다 — 1초마다 물으면 하루 8만 6천 번이다. 그중 의미 있는 답은 몇백 번
• 늦는다 — 10초마다 물으면 주문이 최대 10초 늦게 뜬다

두 선택지 다 나쁘고, 두 번째가 특히 나쁘다. 주방에서 10초는 길다.

큐를 도구 결과가 아니라 리소스로

server.addResource(
  uri: _queueUri,
  name: 'Kitchen queue',
  description: 'Tickets the kitchen still has to make',
  mimeType: 'application/json',
  handler: (uri, params) async => ReadResourceResult(...),
);

그리고 큐가 움직이면 서버가 말한다.

_tickets.add(_Ticket(_next++, _incoming[i++]));
// The whole point. Nobody asked; the server says the queue moved.
server.notifyResourceUpdated(_queueUri);

화면 쪽은 한 번 구독하고 끝이다.

client.onResourceUpdated((uri) async { ... });
await client.subscribeResource(_queueUri);

호출 횟수가 증거다

이런 주장은 말로는 검증이 안 된다. "푸시로 됩니다"라고 써 놓고 뒤에서 폴링하는 코드는 흔하다.

그래서 하니스가 자기가 부른 도구를 센다.

subscribed to orders://queue — from here the screen asks for nothing
--- window opens: tool calls so far 1 ---
told: orders://queue changed (notification 1)
told: orders://queue changed (notification 2)
told: orders://queue changed (notification 3)
--- window closes ---
notifications received: 3
screen updates: 3
tool calls made by the screen inside the window: 0

0. 세 건이 도착하는 동안 화면은 아무것도 안 물었다.

검증이 그 0을 지킨다.

grep -q "tool calls made by the screen inside the window: 0" captures/run.log \
  || { echo "   the screen asked for something — this is polling, not push"; exit 1; }

그리고 화면 정의에도 폴링이 없어야 한다.

if grep -RIqiE '"(poll|interval|refresh|timer)"' kitchen.mbd; then
  echo "   the screen definition is polling"; exit 1
fi