Skip to content
This repository has been archived by the owner on Jun 27, 2024. It is now read-only.
willneedit edited this page Dec 31, 2018 · 3 revisions

AltspaceMREs

The basic concept (and to make it more palatable to external hosting) was to provide a single app which bundles all the other apps into one single instance. Especially for the 'Gate, this also enables the means of inter-app communication and central registry - since it's a single node.js instance hosting all of them.

App selection

The selection logic is in dispatch.ts, which selects a given app out of a name list. MRE URLs are provided in the form of ws://host.service.of.the.mre/app?name=applet, where applet is one of the names provided in dispatch.ts.

Additional parameters

Additional parameters can be provided in an URL encoded form like ws://host.service.of.the.mre/app?name=applet&id=this%20is%20a%20test, in key/value pairs, they will be passed as a mapping into the called applet.

Control connection

Multiplexed into the exported communication endpoint - the port AltspaceMREs export to the outside world - it is possible to employ control connections to the embedded applets. Again the possible endpoints are configured in dispatch.ts to transfer control of the WebSocket connection to a given applet. The control connections are reached via ws://host.service.of.the.mre/control, and the data sent to it must be stringified JSON, where one attribute named 'name' must contain the name of the endpoint - and the data is passed as-is to it. This allows for one incoming connection to 'talk' to different apps, by selecting the intended target on a per-send base.

Caveat: The multiplexing of the control connection is done with internal HTTP proxying - the MRE websocket's baseUrl is set to localhost and thus cannot be used as reference for serving embedded content. Mitigation - Use a different hosting service for static files; that also takes off the heat of the node.js hosting service and saves some computrons.

Clone this wiki locally