Driver

Ein Driver ist ein benannter, wiederverwendbarer Vertrag, an dem sich jedes Backend, jede Application und jede Aufzeichnung ausrichtet. Er deklariert die Leitungen, die das Backend bereitstellen muss, die Worker-Handles, die Konsumenten adressieren können, und die Konfiguration, die der Benutzer auf diesen Handles bereitstellt.

TL;DR

Ein Driver ist eine veröffentlichte Vertragszeile mit drei orthogonalen Kind-Sammlungen — endpoints (Leitungen), workers (allgemeine Worker-Präsenz-Zusicherungen, per Alias adressiert), fills (Konfiguration auf diesen Aliassen).
Eine Application referenziert zwei driver: needs_driver ist der Live-Leitungsvertrag (Transport folgt den UX-Anforderungen — WebRTC, WS, HTTP) und taps_driver ist der Aufzeichnungs- und Replay-Vertrag (immer HTTP, beide Richtungen, in dauerhafte Cloud-Blobs geschrieben).
Ein Backend erfüllt einen driver über EndpointAliases auf seinen vertices. Keine driver_id-Spalte auf dem Backend; die Ausrichtung erfolgt durch role → endpoint_name-Abgleich.
Die Aufzeichnung zählt taps_driver.RequiredEndpoints (beide Richtungen) auf, validiert, dass das Backend einen vertex pro endpoint hat, und überlagert entweder eine HTTP-Tap-URL auf dem Worker (server-gespiegelt) oder fordert die Application zum Dual-Senden auf (client-hochgeladen).

Mentales Modell — Vertrag, nicht Implementierung

Ein Driver ist allem vorgelagert: ein Backend, eine Application und eine Aufzeichnung richten sich alle daran aus, ohne die internen Details der anderen zu kennen. Mehrere Applications können denselben Driver abonnieren und verschiedene Backends konsumieren, die ihn alle erfüllen. Ein anderes Backend mit einer anderen Wahl der Objekterkennungs-component kann dieselbe Application bedienen, solange beide die Vertragsoberfläche des Driver einhalten.

Die drei Sammlungen sind absichtlich unabhängig:

   driver: forklift_perception
   ┌─────────────────────────────────────────────────────────────────┐
   │ endpoints                                                       │
   │  ├─ frames        ingress  [webrtc, http]   required            │
   │  ├─ detections    egress   [http, sse]      required            │
   │  └─ telemetry     egress   [ws, http]                           │
   │                                                                 │
   │ workers (promises)                                              │
   │  └─ detector  fulfills role: detections                         │
   │                                                                 │
   │ fills (config on the worker behind an alias)                    │
   │  ├─ detector.classes      metadata   user-supplied              │
   │  └─ detector.confidence   param      pinned to 0.5              │
   └─────────────────────────────────────────────────────────────────┘

RequiredWorker ist die am häufigsten missverstandene Sammlung. Sie fixiert weder eine component noch eine version noch einen vertex. Sie verspricht, dass ein Worker, der die benannte role erfüllt, unter dem Alias erreichbar ist, mit welchen Fähigkeiten auch immer sein component-Vertrag bereitstellt — metadata_schema-Snapshots (Class-ID-→-Label-Maps, Tokenizer-Vokabulare, Audio-Sample-Rate-Maps), runtime-Abfragen, command / control hooks, fill targets. Der Metadatenabruf ist der häufigste Grund, warum Konsumenten sich darum kümmern, nicht der einzige.

Zwei driver pro Application

Das Application-Manifest referenziert zwei driver-IDs:

Feld	Vertragsrolle	Transport
`needs_driver_id`	Was die Application zur Laufzeit hineinschiebt und herauskonsumiert.	UX-getrieben: WebRTC für Video mit niedriger Latenz, WS für Event-Streams, HTTP für Request / Response.
`taps_driver_id`	Was der Recorder aufzeichnet und das replay erneut ausliefert.	Immer HTTP, beide Richtungen.

Die beiden driver-IDs zeigen oft auf dieselbe driver-Zeile. Dieselben Kanäle, dieselbe (role, name)-Schlüsselung. Live-Konsum wählt den needs_driver-Transport; die Aufzeichnung wählt das taps_driver-HTTP-Overlay. Der Render-Code der Application ist zwischen live und replay identisch, weil die Kanalidentität der Vertrag ist, nicht die Leitung.

Backend-Ausrichtung

Ein Backend erfüllt einen Driver über EndpointAliases auf seinen vertices. Für jeden RequiredEndpoint, den der Driver deklariert, muss irgendein vertex im Backend EndpointAliases[role] == endpoint.name haben, und der Worker dieses vertex muss mindestens einen Transport aus der Allow-List des endpoint akzeptieren, in der richtigen Richtung.

Der Alias-Mechanismus ist das, was den Driver vom Graph entkoppelt: ein Betreiber kann einen YOLO-Detektor gegen den Detektor eines anderen Anbieters austauschen, und solange der neue vertex denselben Alias wiederverwendet, ist der Vertrag des Driver ungebrochen.

Wie die Aufzeichnung `taps_driver` verwendet

Eine Aufzeichnung ist an eine taps_driver_id verankert (typischerweise dieselbe, die das Manifest der Application deklariert). Beim Start zählt der Server taps_driver.RequiredEndpoints (sowohl ingress als auch egress) auf, validiert, dass das Backend über die Alias-Map einen vertex pro endpoint hat, und entscheidet pro Kanal, wie die Aufzeichnung geschieht:

Server-gespiegelt. Der Worker des vertex stellt url und headers Parameter bereit (jeder output_*_http-Worker, jeder input_*_http-Worker). Zur Deploy-Zeit überlagert die Plattform die kanalspezifische Tap-URL und einen Authorization-Header auf die gebundenen Werte des vertex. Der Worker schiebt jeden Frame durch die Tap-Oberfläche; der Backend-Graph selbst bleibt unangetastet.
Client-hochgeladen. Der Worker des vertex kann nicht spiegeln (WebRTC-ingress, der browserseitig hineinstreamt, benutzerdefinierte Worker ohne HTTP-Spiegel). Die Aufzeichnungsantwort markiert needs_client_upload: true für diesen Kanal, und die Application sendet jeden Eingabe-Frame dual durch die Client-Upload-Oberfläche der Aufzeichnung, während sie ihn auch an den Live-ingress schiebt.

Finalize friert einen Snapshot pro Kanal — direction, socket_role, endpoint_name, worker_alias, media_kind, schema und die metadata-Map aus required_fills der Art metadata — in das replay-Manifest ein. Die Wiedergabe emittiert dieselben (role, name)-Schlüssel erneut, die der needs_driver der Application live erzeugt hätte, nur mit cloud-vorsignierten URLs anstelle von Live-Container-URLs.

Kanäle, die die Aufzeichnung in dieser Sitzung nicht erfasst hat, erscheinen weiterhin in der endpoints[]-Liste des Manifests, damit der Player die volle driver-Vertragsoberfläche rendern kann (ein leeres Fenster für einen nicht aufgezeichneten egress, ein Platzhalter für einen nicht aufgezeichneten ingress).

Ausführen

Driver werden vorgelagert (Katalog, Application-Authoring) erstellt und von Applications und Aufzeichnungen referenziert. Das Application-Manifest ist der Ort, an dem die meisten Benutzer einem Driver begegnen — siehe /concepts/applications für die Manifest-Form und /concepts/replays für die Aufzeichnungs-/Wiedergabeoberfläche, die taps_driver konsumiert.

Verwandt

Applications — referenziert driver über needs_driver_id und taps_driver_id.
Backends — EndpointAliases ist der Ausrichtungsmechanismus.
Replays — Aufzeichnung und Wiedergabe über taps_driver.
Solutions — die veröffentlichte Einheit, die Backend + Application + driver-Ausrichtung bündelt.