Websocket server does not start

[almereyda]

When running https://hub.docker.com/r/federatedwiki/distribution/~/dockerfile/ through

docker run -p 3000:3000 -v /home/yala/src/lab.allmende.io/configurations/remote-wikifarm/:/root/.wiki/ -it --rm federatedwiki/distribution

on top of a /root/.wiki/ git archive, a Websocket connection cannot be established in http://localhost:3000/view/about-linkmap-plugin/view/linkmap-network-diagram (Host header is spoofed to an actual domain of the archive), there simply will be null response. Terminal output knows more:

linkmap startServer [ 'argv', 'app' ]
failed to start plugin wiki-plugin-linkmap TypeError: One of the "port", "server", or "noServer" options must be specified
    at WebSocketServer (/usr/local/lib/node_modules/wiki/node_modules/ws/lib/websocket-server.js:53:13)
    at Object.startServer (/usr/local/lib/node_modules/wiki/node_modules/wiki-plugin-linkmap/server/server.js:95:14)
    at /usr/local/lib/node_modules/wiki/node_modules/wiki-server/lib/plugins.coffee:32:22
    at FSReqWrap.cb [as oncomplete] (fs.js:259:19)

[almereyda]

I suppose this is due to adaptations which only got forgotten to be implemented in wiki-server after https://github.com/fedwiki/wiki-plugin-linkmap/pull/7 got merged?

There are some associated changes need in wiki-server to add back the server as a parameter when starting the plugin server.

[WardCunningham]

I doubt that plugin has been tested in a docker environment. We also routinely put reverse proxies and other layers of http/https messing around that could get in the way.

[almereyda]

The reverse proxy option kind of eased out with https://socio.federated.wiki/t/linkmap/13/6

Nicely enough the error message hints us what might be wrong here:

One of the "port", "server", or "noServer" options must be specified

I guess we just never saw an example of that in the wild?

[paul90]

Question: Does this plugin really add anything? Is there any reason it uses sockets rather than a simple get?

Looking at the code, the linkmap is constructed at server startup and then is never updated.

I could understand the use of sockets if the linkmap was getting updated as the sites contents was changed, and an updated linkmap was pushed out to the client when it was changed. But currently it is static, so it is quite pointless to use sockets.

In it's current state, I would suggest that this plugin is essentially pointless. While the idea is interesting, currently it presents a snapshot of the links in a site at some point in time at is unlikely to be known to the user and for all but a static site is going to present a view of the site that will most likely be out of date.

[paul90]

Let's not forget this from the about page...

This plugin uses websockets to communicate with its server-side half. This anticipates long running, low latency, continuous updates but does not choose to offer this yet.

This was written 5 years ago!

[WardCunningham]

Yes, this was an experiment where the server-side graph was the most immediately available data worth sending. I wrote this with @hallahan.

https://github.com/hallahan?tab=overview&from=2012-12-01&to=2012-12-31

The later work below was the highpoint for websockets where I had two-way async communication between client running slow speed calculations in the browser while talking through the server and the attached usb to a microcontroller running high-speed code snippets constructed in the client. This was one of my last videos recorded five years ago which was also when I took another full-time job.

http://video.fed.wiki.org/22-things-txtzyme-websocket-plugins.html

My vision then would be that our current plugin to plugin discovery mechanism would just setup two-way pipelines between realtime modules within the client and with server-side parts of the communicating clients. I think the infatuation with pipes has waned in the node community too. But it could have been awesome.