WBS: the first fixtures are in, and what byte-for-byte means
This commit is contained in:
@@ -221,17 +221,27 @@ quietly carried traffic would be step 5 arriving early and unrehearsed.
|
|||||||
that decides what "agreeing" means for everything after it. It is the largest step and the one that
|
that decides what "agreeing" means for everything after it. It is the largest step and the one that
|
||||||
pays for itself furthest away.
|
pays for itself furthest away.
|
||||||
|
|
||||||
- [ ] 3.1 **the suite first, on the bus the mesh has** — fixtures for the envelope and its required
|
- [x] 3.1/3.3 **the fixtures** — one directory in the sdk, read by each implementation's own
|
||||||
headers, the contributions file, a served tool call and a grant, capturing what the three
|
runner rather than copied into either, because a fixture copied twice is two fixtures. The
|
||||||
implementations do *today*. Written first because a suite born on the new bus certifies
|
Go emitter and the runtime's NATS client both pass the first: every required header set,
|
||||||
whatever the new bus happens to do
|
each value in the pinned shape, the subject derived the same way, and the payload the body
|
||||||
|
alone.
|
||||||
|
|
||||||
|
**The suite also had to settle what "byte-for-byte" can mean**, which ADR 0074 stated and
|
||||||
|
nothing had yet had to implement. The envelope is exact — subject, required headers, names
|
||||||
|
and formats — because that is what two implementations get wrong invisibly. The body is
|
||||||
|
not: Go sorts a map's keys and JavaScript keeps insertion order, so identical bytes would
|
||||||
|
commit every implementation to a canonical JSON encoder, to buy a property the mesh never
|
||||||
|
uses. Read strictly it would have sent somebody writing one.
|
||||||
|
|
||||||
|
Still to capture: a served tool call, a grant and its answer, and the contributions file —
|
||||||
|
the other three ADR 0074 names.
|
||||||
- [x] 3.2 design 19 rewritten from exchanges, queues and routing keys to the subjects and streams of
|
- [x] 3.2 design 19 rewritten from exchanges, queues and routing keys to the subjects and streams of
|
||||||
design 25 §2–§3, per capability, with ADR 0074's model untouched: floor plus capabilities, an
|
design 25 §2–§3, per capability, with ADR 0074's model untouched: floor plus capabilities, an
|
||||||
implementation legitimate when it claims less, identity from the sealed credential, dedup on
|
implementation legitimate when it claims less, identity from the sealed credential, dedup on
|
||||||
`x-event-id`. Claims checked against a running server are marked *verified* in the text, so
|
`x-event-id`. Claims checked against a running server are marked *verified* in the text, so
|
||||||
a reader can tell what was measured from what was reasoned. One limitation lifts with the
|
a reader can tell what was measured from what was reasoned. One limitation lifts with the
|
||||||
transport: a module may now call another's tool, which issue 049 recorded it could not.
|
transport: a module may now call another's tool, which issue 049 recorded it could not.
|
||||||
- [ ] 3.3 the fixtures restated on NATS, and the capability each implementation claims
|
|
||||||
- [ ] 3.4 the controller's link on NATS
|
- [ ] 3.4 the controller's link on NATS
|
||||||
- [ ] 3.5 the host's link on NATS — mirroring, still importing nothing
|
- [ ] 3.5 the host's link on NATS — mirroring, still importing nothing
|
||||||
- [x] 3.6 the tool runtime's client on NATS, behind the unchanged sdk contract — round-tripped
|
- [x] 3.6 the tool runtime's client on NATS, behind the unchanged sdk contract — round-tripped
|
||||||
|
|||||||
Reference in New Issue
Block a user