Driver'lar

Bir Driver, her Backend'in, Application'ın ve recording'in hizalandığı adlandırılmış, yeniden kullanılabilir bir sözleşmedir. Backend'in açması gereken kabloları, tüketicilerin adresleyebileceği worker tutamaçlarını ve kullanıcının o tutamaçlar üzerinde sağladığı yapılandırmayı bildirir.

Özet

Bir Driver, üç dik alt koleksiyonu olan yayımlanmış bir sözleşme satırıdır — endpoint'ler (kablolar), worker'lar (alias ile adreslenen genel amaçlı worker varlığı vaatleri), fill'ler (o alias'lar üzerindeki config).
Bir Application iki driver'a referans verir: needs_driver canlı kablo sözleşmesidir (taşıma UX ihtiyaçlarını izler — WebRTC, WS, HTTP) ve taps_driver yakalama ve replay sözleşmesidir (daima HTTP, her iki yön, kalıcı bulut blob'larına yazılır).
Bir Backend bir driver'ı vertex'lerindeki EndpointAliases üzerinden karşılar. Backend'de driver_id sütunu yoktur; hizalama role → endpoint_name eşleşmesiyle olur.
Recording, taps_driver.RequiredEndpoints'i (her iki yön) numaralandırır, Backend'in endpoint başına bir vertex'e sahip olduğunu doğrular ve ya worker üzerine bir HTTP tap URL'i kaplar (sunucu-yansıtmalı) ya da Application'dan çift-göndermesini ister (istemci-yüklemeli).

Zihinsel model — sözleşme, implementasyon değil

Bir Driver her şeyin yukarısındadır: bir Backend, bir Application ve bir recording, birbirlerinin iç yapısını bilmeden ona göre hizalanır. Birden fazla Application aynı Driver'a abone olabilir ve hepsi onu karşılayan farklı Backend'leri tüketebilir. Farklı bir nesne-algılama component seçimine sahip farklı bir Backend, ikisi de Driver'ın sözleşme yüzeyine uyduğu sürece aynı Application'a hizmet edebilir.

Üç koleksiyon kasıtlı olarak bağımsızdır:

   driver: forklift_perception
   ┌─────────────────────────────────────────────────────────────────┐
   │ endpoints                                                       │
   │  ├─ frames        ingress  [webrtc, http]   required            │
   │  ├─ detections    egress   [http, sse]      required            │
   │  └─ telemetry     egress   [ws, http]                           │
   │                                                                 │
   │ workers (vaatler)                                               │
   │  └─ detector  rolü karşılar: detections                         │
   │                                                                 │
   │ fills (alias arkasındaki worker üzerindeki config)              │
   │  ├─ detector.classes      metadata   kullanıcı-sağlamalı        │
   │  └─ detector.confidence   param      0.5'e sabitlenmiş          │
   └─────────────────────────────────────────────────────────────────┘

RequiredWorker en çok yanlış anlaşılan koleksiyondur. Bir component'i, bir versiyonu veya bir vertex'i sabitlemez. Adlandırılmış role'ü yerine getiren bir worker'ın, component sözleşmesinin açtığı her ne yeteneklerle olursa olsun, alias üzerinden erişilebilir olduğunu vaat eder — metadata_schema anlık görüntüleri (class-id → label eşlemeleri, tokenizer vocab'ları, ses örnekleme oranı eşlemeleri), runtime sorguları, command / control kancaları, fill hedefleri. Tüketicilerin önemsediği en yaygın neden metadata getirmedir, tek nedeni değil.

Application başına iki driver

Application manifest'i iki driver ID'sine referans verir:

Alan	Sözleşme rolü	Taşıma
`needs_driver_id`	Application'ın runtime'da içeri ittiği ve dışarı tükettiği.	UX-güdümlü: düşük gecikmeli video için WebRTC, olay akışları için WS, istek / yanıt için HTTP.
`taps_driver_id`	recorder'ın yakaladığı ve replay'in yeniden sunduğu.	Daima HTTP, her iki yön.

İki driver ID'si genellikle aynı driver satırına işaret eder. Aynı kanallar, aynı (role, name) anahtarlaması. Canlı tüketim needs_driver taşımasını seçer; recording taps_driver HTTP kaplamasını seçer. Application'ın render kodu canlı ve replay arasında aynıdır çünkü kanal kimliği sözleşmedir, kablo değil.

Backend hizalaması

Bir Backend bir Driver'ı vertex'lerindeki EndpointAliases üzerinden karşılar. Driver'ın bildirdiği her RequiredEndpoint için, Backend'deki bir vertex'in EndpointAliases[role] == endpoint.name olması gerekir ve o vertex'in worker'ı endpoint'in izin listesindeki en az bir taşımayı, doğru yönde kabul etmelidir.

Alias mekanizması Driver'ı grafikten ayrıştıran şeydir: bir operatör bir YOLO dedektörünü farklı bir satıcının dedektörüyle değiştirebilir ve yeni vertex aynı alias'ı yeniden kullandığı sürece Driver'ın sözleşmesi bozulmaz.

Recording `taps_driver`'ı nasıl kullanır

Bir recording bir taps_driver_id'ye sabitlenir (tipik olarak Application'ın manifest'inin bildirdiği aynı olan). Başlangıçta sunucu taps_driver.RequiredEndpoints'i (hem ingress hem egress) numaralandırır, Backend'in alias eşlemesi üzerinden endpoint başına bir vertex'e sahip olduğunu doğrular ve yakalamanın nasıl gerçekleştiğine kanal başına karar verir:

Sunucu-yansıtmalı. vertex'in worker'ı url ve headers parametrelerini açar (her output_*_http worker'ı, her input_*_http worker'ı). Deploy zamanında platform, kanal başına tap URL'ini ve bir Authorization başlığını vertex'in bağlı değerlerine kaplar. Worker her frame'i tap yüzeyi üzerinden iter; Backend grafiği kendisi dokunulmadan kalır.
İstemci-yüklemeli. vertex'in worker'ı yansıtamaz (tarayıcı tarafında akan WebRTC ingress, HTTP yansısı olmayan özel worker'lar). recording yanıtı o kanal için needs_client_upload: true işaretler ve Application her giriş frame'ini recording'in istemci-yükleme yüzeyi üzerinden çift-gönderirken aynı zamanda canlı ingress'e de iter.

Finalize, kanal başına bir anlık görüntüyü — direction, socket_role, endpoint_name, worker_alias, media_kind, schema ve metadata türünden required_fills'ten kaynaklanan metadata eşlemesi — replay manifest'ine dondurur. Playback, Application'ın needs_driver'ının canlı olarak üreteceği aynı (role, name) anahtarlarını, yalnızca canlı container URL'lerinin yerine bulut-önimzalı URL'lerle yeniden yayar.

recording'in bu oturumda yakalamadığı kanallar, oynatıcının tam driver-sözleşmesi yüzeyini render edebilmesi için manifest'in endpoints[] listesinde yine de görünür (yakalanmamış bir egress için boş bir bölme, yakalanmamış bir ingress için bir yer tutucu).

Çalıştır

Driver'lar yukarı akışta yazılır (katalog, Application yazımı) ve Application'lar ve recording'ler tarafından referans verilir. Çoğu kullanıcının bir Driver'la tanıştığı yer Application manifest'idir — manifest şekli için /concepts/applications'a ve taps_driver'ı tüketen recording / playback yüzeyi için /concepts/replays'e bakın.

İlgili

Application'lar — driver'lara needs_driver_id ve taps_driver_id üzerinden referans verir.
Backend'ler — EndpointAliases hizalama mekanizmasıdır.
Replay'ler — taps_driver üzerinden yakalama ve playback.
Solution'lar — Backend + Application + driver hizalamasını paketleyen yayımlanmış birim.