From b03f5193b8c4dd667e103bb72f1c57a94c99d039 Mon Sep 17 00:00:00 2001 From: jochen Date: Thu, 12 Nov 2026 18:54:23 +0100 Subject: [PATCH] =?UTF-8?q?Design=2047=20G=20=C2=A7717:=20a=20follower=20h?= =?UTF-8?q?ears=20its=20seat's=20holder=20from=20the=20seat-holders=20view?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A seat's view is said on its holder's module subject, so a follower must know the holder; asking for it every 5 seconds was polling and kept a holder that moved. It now follows the seat-holders view as A-295's holder function does, reached from the catalog half's claim, and re-follows when the holder changes. Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h --- .../G-21-provider-and-revert-ask.md | 57 ++++++++++++------- 1 file changed, 36 insertions(+), 21 deletions(-) diff --git a/03-DESIGN/01-to-be/47-milestones/G-21-provider-and-revert-ask.md b/03-DESIGN/01-to-be/47-milestones/G-21-provider-and-revert-ask.md index 7c1fde0a..6cff9b09 100644 --- a/03-DESIGN/01-to-be/47-milestones/G-21-provider-and-revert-ask.md +++ b/03-DESIGN/01-to-be/47-milestones/G-21-provider-and-revert-ask.md @@ -307,7 +307,7 @@ design's choice within the record it cites, tested against [the principles](../. - §717 **The status view's answers are a view of the seat `mesh-delivery-view`, the assigner's asks and wants are views of the seat `mesh-wants`, and a follower finds each by its seat and starts without it.** (ADR 0540 §1, §6; ADR 0429 §3; ADR 0567 §5, §6; ADR 0571 §6; ADR 0565; ADR 0539 §16; ADR 0596; §7, §200, §428, §532, §616, §699, - §710, A-126, A-131, A-175, A-178, A-210) This answers developer J27's question of 2026-11-12, met building A-210 + §710, §614, A-126, A-131, A-175, A-178, A-210, A-295) This answers developer J27's question of 2026-11-12, met building A-210 and A-296 (G-22): A-210 has a part find another module as the holder of the seat it holds, but the status view claims no seat while the teller follows its `answers` by its module name, and the assigner holds two seats while the teller follows its `asks` by its module name. It completes A-175 and A-178 for both views. @@ -340,25 +340,40 @@ design's choice within the record it cites, tested against [the principles](../. `seat:mesh-module-assigner.views.assignments` in place of the three `mesh-delivery-assigner.views` entries, and its `invokes` loses `assigner_read_asks`, `assigner_read_wants` and `assigner_read_assignments`. Neither part's code names the assigner or the status view (§7, §428). - - **A follower starts before the holder is known.** mesh-sdk's `views.ProcessReader` gains `FollowSeat`, given a - seat and a state: it returns at once a picture that reads as empty, its follower not ready, and never fails for - want of a holder. In its own goroutine it asks `seatlist.HolderOf` for the seat through the process's calls; a - failed ask is said in the process's journal, naming the seat and the error, and asked again 5 seconds later, - until it answers or the process stops. Meanwhile the follower's status names the seat in place of its owner, - waiting since the start, and past five minutes the reader writes §200's `view-waits` naming the seat and the - state, cleared when the first view arrives. Once the seat's holder H is known it follows as `Follow` does after - `Start` (§532): the first view asked of H's tool named for the state, then H's views family. The holder found is - kept for the life of the process, and a new holder is followed from the follower's next start. The teller's two - follows and the status view's three go through `FollowSeat`, each apart, so the teller raises the assigner's - asks whether or not the status view's answers are read (issue 1906, as today). The builder's and the checker's - own loop for the assignments, buildrun's `AssignerHolder`, goes: both follow `assignments` through `FollowSeat`. + - **What the seat form puts on the bus.** A seat's view is said where its holder says it, on the holder's own + subject `mesh.mod..event.views.`, and the grants part resolves a `consumes` entry + `seat:.views.` to that subject for the seat's holder on record, granting nothing while the seat has + none (§616). The subject is module-scoped, so a follower must know the holder, and follows it as it moves. + - **A follower finds and re-finds the holder from the seat-holders view.** mesh-sdk's `views.ProcessReader` gains + `FollowSeat`, given a seat and a state, and the holder function A-295 gives a part, which answers from what the + part last heard of the seat `mesh-module-assigner`'s view `seat-holders`. The part follows that view as the tool + runner does (§616): the module that claims `mesh-module-assigner` is read from the catalog half the part follows + (§614, the trunk's entry whose manifest `claims` the seat), so no code names the assigner's module; the view is + named `seat:mesh-module-assigner.views.seat-holders` in the part's `consumes`, its first view asked of the + claimant's tool `seat-holders`, and a catalog revision naming another claimant drops it and follows the new one + (§532). `FollowSeat` returns at once a picture that reads as empty, its follower not ready, and never fails for + want of a holder. At each change of the seat-holders view it reads the seat's holder: on a first holder it follows + as `Follow` does after `Start` (§532), the first view asked of the holder's tool named for the state, then its + views family; on another holder it drops the view of the old one and follows the new one, the picture handing on + the new holder's state whole; with no holder it keeps the picture it has and follows nothing. Nothing is asked + again on a timer. While no holder is followed the follower's status names the seat in place of its owner, waiting + since its start or since its holder left, and past five minutes the reader writes §200's `view-waits` naming the + seat and the state, cleared when a holder's first view arrives. The teller's two follows and the status view's + three go through `FollowSeat`, each apart, so the teller raises the assigner's asks whether or not the status + view's answers are read (issue 1906, as today); the teller gains the catalog half's reader of §614 for this. The + builder's and the checker's own loop for the assignments, buildrun's `AssignerHolder`, which asks every 5 seconds, + goes: both follow `assignments` through `FollowSeat`. `seatlist.HolderOf`'s call stays for a caller that asks + once, as A-210 has it. Why: ADR 0540 §1 already names the seat the status view holds, and §616 and §699 give a view named by its seat; - `asks` goes where the kinds it holds belong, its proposal kind kept with them so the teller follows one view, and - the holder is found as A-210 has it, asking again and never stopping a start (principles 1, 3, 7 and 8). How it is - checked: unit (mesh-sdk `views`), a `FollowSeat` whose holder ask fails twice returns at once, writes `view-waits` - naming the seat past five minutes, then takes its first view from `.` and hears the holder's family; - unit (manifest validator), `seat:mesh-delivery-view.views.answers` and `seat:mesh-wants.views.asks` accepted, a seat - view of a state without `view` refused; whole (teller), started before any module holds `mesh-wants`, it raises an - assigner's ask once the holder is placed, and takes an answer the status view writes; the code review, no module - name of the assigner or the status view in the teller's, the status view's, the builder's or the checker's code. + `asks` goes where the kinds it holds belong, its proposal kind kept with them so the teller follows one view. The + holder is heard from the seat-holders view as A-295 has it, never asked on a timer, and a moved holder is followed + as it moves (principles 1, 3, 7 and 8). How it is checked: unit (mesh-sdk `views`), a `FollowSeat` with no holder + returns at once and writes `view-waits` naming the seat past five minutes; a seat-holders change naming a holder + takes its first view from `.` and hears its family; a second change naming another holder drops the + first and follows the second; no ask is made between changes. Unit (manifest validator): + `seat:mesh-delivery-view.views.answers` and `seat:mesh-wants.views.asks` are accepted, and a seat view of a state + without `view` is refused. Whole (teller): started before any module holds `mesh-wants`, it raises an assigner's + ask once the holder is placed, and takes an answer the status view writes. The code review: no module name of the + assigner or the status view in the teller's, the status view's, the builder's or the checker's code, and no + timer that asks for a holder again.