Object Store (IndexService)

The web service edits backend objects by key. Common/IndexService.cs is one process-wide store — a concurrent dictionary from string key to object, registered as a singleton — that every geometry, transformer and widget controller reads and writes. A create or index route puts an object in the store under a key and returns the key; per-kind routes then edit the object through that key, so an edit lands on the very instance the project holds.

Keys

Keys are plain strings chosen by the caller; a route given no key mints a GUID. A route that creates an object returns its key as a bare string (plain text unless the request asks for JSON); a few, such as the cutter's upper-beam create, answer a JSON object that carries it.
Container routes derive child keys from the parent's: <key>-Geom and <key>-Transformer from a transformation geometry; <sessionKey>-Workpiece, -RawGeom and -IdealGeom from the workpiece's Initialize; <sessionKey>-Fixture alone from the fixture's; and -HolderCylindroid from a cylindroid holder. A vector is never given a key of its own: the translation, axis or pivot of a transformer and the corners of a box are written through their owner's key. A part's anchors and branches are not keyed by these routes: the topology editor mints equipment-topology.<owner>.branch.<guid>.transformer and equipment-topology.<owner>.anchor.<guid>.geom on demand, and the worktable attachment's transformer sits under equipment-topology.equipment.table-to-comp.
The store is not scoped to a connection, a user or a page. Every browser and script connected to the service shares it, and writing an existing key repoints it without a word; only POST /api/Index/Alias refuses a key already in use, with 409.
The typed lookup the controllers share answers 404 for a missing key and 409 for a key holding the wrong type.

Lifetime

Two client-driven paths evict an entry (a few routes also drop the keys they minted themselves, e.g. the STL preview's transform key); a key none of them covers stays for the life of the process. The browser bounds the store: wwwroot-src/src/composables/useCleanupHub.ts keeps the keys a component registered and posts POST /api/Index/Remove for each of them when that component unmounts, and a component posts the same call for a key it is about to replace. Common/CleanupHub.cs covers the connection drop: 90 seconds after a client's connection drops, the keys it registered with Add are evicted unless a live connection holds them by then (the client registers its keys again when it reconnects); see WebAPI Hub Cleanup Pattern. Removing a key forgets the handle only; the object stays in the project.

An Edit Through a Key Is a Setup Edit

The object behind a key is the authored setup object, not the runtime copy the runner plays against. That copy is rebuilt from the setup when an install route marks the setup edited and at the start of every fresh session; an edit made through a child key marks nothing. So every host re-posts the owning slot's install route after an inner edit — see Workpiece and Fixture for the browser's chains, and Driving the Web Service over HTTP for the same obligation on a script.

Source Code Path

See HiNC App Anatomy for git repository links.

Web Application

HiNC-2025-webservice (Quasar CLI SPA):

Common/IndexService.cs — the store and its typed lookup with the 404 / 409 answers.
Common/IndexController.cs — GetType, Get, Remove and Alias under /api/Index.
Program.cs — the singleton registration.
Common/CleanupHub.cs — the hub that evicts a dropped connection's registered keys after a grace period, unless a live connection holds them by then.
wwwroot-src/src/composables/useCleanupHub.ts — the browser-side key set and its removal calls.

HiAPI Engine

HiNc/MachiningProcs/LocalProjectService.cs — the setup-edited flag and the rebuild of the runtime equipment at an install and at a fresh session.

Table of Contents