NikolaySuslov
commented
5 years ago Hello Reggie,
Current standalone reflector, which is used at Livecoding.space project is almost the same as in the original VWF (concerning functionality: handling messages and replication of initial state). The only difference is in getting VWF app info for connection. The original VWF reflector depends on file storage system, just look at #parseSocketUrl( socket ) function, that contains the call to #parseurl.Process( namespace ).
The standalone version was developed with an aim to eliminate file storage system dependence. The current solution is in getting VWF app info right from the client, using query in options during Websocket connection. Look at VWF.js for #ready(component_uri_or_json_or_object, path) function, where path is gotten by calling #getApplicationState() in app.js. Current lcs-v0.2 version is based on Gun DB and collects VWF app information right from the distributed DB. Previous version uses reflector's code for working with file storage system, but instead of delegating the parsing process of an URL to the reflector (as in original VWF), it sends POST request with '/parseurl' to an app hosting server (look at version lcs-v0.1 https://github.com/NikolaySuslov/livecodingspace/blob/lcs-v0.1/support/client/lib/vwf.js).
The #getWebAppUpdate message in reflector.js is used only for emitting information about running instances for the front web page (or world details page), so it does not affect the main reflector logic.
All that means, that yes you could use standalone reflector for any original VWF app (ThreeJS, A-Frame, no driver.. etc.), but choosing what storage system your VWF app depends on.
In the original VWF: app hosting server and reflector server interlace together and depends on OS file storage system.
In Livecoding.space as of lcs-v0.2, app hosting server and reflector are standalone. VWF apps entirely depend on Gun DB storage system and does not contain code for the original VWF ThreeJS drivers.
Version lcs-v0.1 depends on file system storage, but could use the standalone reflector (no app saving), also there are no VWF ThreeJS drivers.
So, I would like to suggest you to restore the needed client specific ThreeJS drivers from the original VWF (and modifying VWF.js, pointing in code to that corresponding drivers, as in original version). In the lcs-v0.2 version, you will need also to make a setup (filling DB) with a ThreeJS node prototypes and sample worlds.
Best regards, Nikolai
lazydino
Hi Nikolay,
I am trying to migrate our VWF applications with your standalone reflector by updating our VWF node js server code. The main difference between the VWF server code of yours and mine is our server application is based on the original one that serves three JS applications, and yours are A-frame. I am applying a strategy of gradually updating my lib/nodejs/ directory and find out what are require to change mainly on reflector.js.
Livecoding codebase under lib/nodejs/ at or before commit d11185 done on 12/27/2017 works fine, and I was able to run the three js duck demo without problems. The Jan 30 2018 commit at 8b2542 won't render the duck at all. The different updates on reflector.js is the deal breaker.
It looks like the web app would have to respond to special websocket topic of 'getWebAppUpdate' to get render and reflected. Can you tell me what are the major programming tasks need to be performed to run with your reflector? I presume the standalone or remote version of reflector can work with any VWF applications Server whether it could serve A-Frame component or not.