-
Notifications
You must be signed in to change notification settings - Fork 8
Home
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.
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 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.
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.