glm-5.1
1306716897
19 tasks covering core testing, Redis hardening, WebSocket client/server adapters, Worker adapter, and final review gates. Iroh adapters are tracked as a deferred placeholder blocked on the @alkdev/iroh fork. Phases: core validation → Redis hardening → review gate → WebSocket adapters → review gate → Worker adapter → review gate → final validation.
1.6 KiB
1.6 KiB
id: worker-adapter-rd
name: R&D on Worker adapter: Node vs Web Worker API differences
status: pending
depends_on: [review-core-and-redis]
scope: narrow
risk: medium
impact: component
level: implementation
Description
The Worker adapter has an open question documented in docs/architecture/event-targets/worker.md: should we implement one adapter that targets Web Workers (browser + Deno + Bun), two separate adapters for Node worker_threads and Web Workers, or one adapter abstracting both?
The architecture doc recommends starting with a single adapter targeting Web Workers (browser + Deno + Bun all support this API). Node worker_threads support would be added later.
This R&D task should:
- Evaluate the API differences between Web Worker (
self.onmessage/self.postMessage) and Nodeworker_threads(parentPort.on('message')/parentPort.postMessage()) - Determine if a single adapter abstraction is feasible and worth the complexity
- Decide on the initial scope: Web Worker only, or both from the start
- Identify any polyfills or compatibility shims needed
Acceptance Criteria
- R&D notes documented on the API differences between Web Worker and Node worker_threads
- Decision made on scope: single Web Worker adapter, or dual adapter from the start
- If dual adapter, create separate task for the Node worker_threads variant
- If single adapter, identify what runtime detection or abstraction is needed
References
- docs/architecture/event-targets/worker.md (Open Questions section)
Notes
To be filled by implementation agent
Summary
To be filled on completion