Enhance RemoteMethodAccess to Support Instance-to-Instance Routing

Input from Gemini 3.1 Pro:

✦ I have successfully implemented and merged the enhancement to the RemoteMethodAccess (RMA) mixin.

Architectural Briefing: Instance-to-Instance IPC

For future developers and AI agents reviewing this architecture, it is critical to understand how RMA now bridges the isolated memory spaces of different worker threads.

The Challenge: Each worker thread (App Worker, Data Worker, etc.) has its own completely isolated Javascript memory space, its own idCounter, and its own Neo.manager.Instance registry. Because of this, an ID like pipeline-1 might exist in both the App Worker and the Data Worker simultaneously, but they refer to completely different objects in their respective memory spaces.

The Solution: The Illusion of Global IDs & The Handshake We bypass this limitation not by creating truly global IDs, but by exchanging local IDs between threads in a "Handshake":

1. The Handshake (Exchange of Local IDs): When an instance in the App Worker (e.g., App-Pipeline, local ID: app-pipe-1) wants to spawn a counterpart in the Data Worker, it sends a createInstance IPC message. Crucially, it includes its own ID in the config payload sent over the wire: { appPipelineId: 'app-pipe-1' }. The Data Worker receives this, creates its own local instance (e.g., Data-Pipeline, local ID: data-pipe-4), and replies with its newly generated ID. Now, both instances know the local ID of their counterpart in the other thread's memory space.

2. The Execution (Bi-Directional RMA): We enhanced src/worker/mixin/RemoteMethodAccess.mjs to recognize a new remoteId property in IPC messages.

   • App -> Data: When the App Worker wants to execute read() remotely, it calls this.generateRemote({ origin: 'data', id: 'data-pipe-4' }, 'read'). When this message arrives in the Data Worker, RMA intercepts it, sees remoteId: 'data-pipe-4', and successfully looks it up in the Data Worker's local Instance manager.
   • Data -> App: When the Data Worker needs to push streaming data back, it uses the ID it received during the handshake: this.generateRemote({ origin: 'app', id: 'app-pipe-1' }, 'onParserData'). This message arrives in the App Worker, and RMA finds it in the App Worker's local registry.

Summary By adding msg.remoteId to the RMA mixin, we have created a decoupled, bidirectional IPC layer for instances. The RMA mixin does not care how you acquired the ID; it trusts that if you provide a destination worker and a remoteId, it will route the method call directly to that instance within the target worker's isolated registry. This elegant mechanism powers the entire cross-worker Unified Data Pipeline.