| Filename | Latest commit message | Latest commit date |
|---|---|---|
24cd7f6d65
`Node` carried two of the three lifecycle timestamps; the third lived on hive-c0re's `NodeKind::Dag` container payload, a core-specific wrapper the graph knows nothing about. Give it its real home so the container's copy becomes redundant rather than load-bearing. Not an `Option` like its neighbours: starting and finishing are events that may never happen, but a node that exists was created. Modelling it as optional would encode a state the graph cannot be in. `hive-jobq-wire::GraphNode` gains the field in the same commit — it already carries the other two, and without this one the value cannot reach a viewer when the container's copy is deleted. |
||
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
hive-jobq-wire
Wire types for serving a hive-jobq graph to a viewer, plus
the traits a host implements to say how its graph renders.
Why this is not part of hive-jobq. The scheduler crate is logic: a graph,
a resource pool, a run loop. Presentation is a different concern with a
different audience, and folding it in means every consumer of the scheduler
also carries a JSON vocabulary it may never serve — the two get remixed and
stay that way. A separate crate keeps that boundary where it can be seen.
A host implements WireNode for its node payload N and WireResource for
its resource name R. GraphWire::wire_snapshot is then blanket-implemented
for hive_jobq::Graph<N, R> — so the projection exists exactly when both types
have said how they render, and a payload that hasn't cannot reach a viewer at
all.