To open other web-socket communication during service?

[JimCSuen]

I would like to GET other online resources so as to introduce more additional information in the frontend displaying. However, I have no idea on how and where or even if it is possible for me to open a web-socket on another unoccupied port other than the used one of GLSP? I have tried to use axios.get() in render functions (it sounds like a wrong usage, i know). Though the msg was sent successfully as long as the server receives and responds successfully, the render function catches up with NETWORK ERROR and could not read the reply message. I thought there might be a port usage conflict? So then I decide to change the axios port using http package to create an http.agent() instance. However, I could now yarn successfully, which comes up with ERR: could not find http in .../.../...-client/lib ... BREAKING CHANGE, ..., something like that. However, I did add the dependencies requirement of http in the devDependencies and dependencies of package.json.

I think that my usage might be wrong. So, i want to know if there is any possible correct way to do online resource GET?

[martin-fleck-at]

Hi @JimCSuen, I'm not fully sure what it is you are trying to do, could you please elaborate a bit more on what integration you are using (standalone, Theia, VS Code, ...) and what online resource you are trying to query (from the server?).

[JimCSuen]

Hi @martin-fleck-at, I'm sorry for the ambiguity of my problem.

I'm using Theia-glsp-integration to build my work, based on both the example of "workflow" in "glsp-examples" and "tasklist" of "node-json-theia".

Now I'm trying to build a platform into a simplified SCADA (supervisory control and data acquisition) system used in industrial control system. To be more clear, I'm working on a similar situation like the following:

• the local source model file gives the basic diagram components to be randered.
• the specific randering of components, i.e., the type of view, is dependent on the real-time state provided elsewhere, instead of included in the local source model file.
• the reason to provide the real-time state elsewhere is that, all the components in the diagram are mapped to a set of running devices someplace. Users need to get knowledge about the real-time state of those running devices, which could not be reflected in the offline local source model file, and is only available on other servers through a url (where the state of devices would be uploaded to). So, we have to make it possible inside the Theia-glsp app for the resource to be obtained through web-communication, e.g., a restful-api way using GET.

Though we could use other realizations, e.g., python, to querying the real-time state and re-write the source model in real-time, then trigger the re-randering in the Theia-glsp app, it would be less complex with the above logic. So, I still would like to know whether that is possibleto do the above functions?

[martin-fleck-at]

So if I understand you correctly, what you do in your case is to use the file as a basis and then use real-time information to create the final model that should be rendered, is that right?

In general in GLSP the source of truth (i.e., the source of the model to be rendered) is the GLSP server. So in your case, I'd assume hat your source model storage would read the file opened by the user to get the model, read and register for updates of that model on the external server (through a URL), enrich the model with the dynamic information and create a GModel based on that. On every update of the dynamic information, we trigger a re-creation of that model and send it down to the client.

Alternatively, as you suggested, you could do the retrieval and re-generation trigger on the client side, but I don't think that this has any benefits or am I overlooking something here?

I'd hope that you may not run into similar problems on the server since this is a pure Node process whereas most of the client-side is executed in the browser only.

[JimCSuen]

Yes, @martin-fleck-at your understanding and assumptions are absolutely correct.

So, it is possible and recommended to do these kind of real-time online communication on the server side through a URL, right?

[martin-fleck-at]

It is definitely possible! Whether it is recommended really depends on how much influence the real-time updates have on the model and how any updates you expect. If it is just very minor things, you could do it on the client-side and simply modify the SVG directly (to avoid re-rendering of unchanged parts). However, if the changes are more substantial, I'd recommend doing it on the server-side since it is much cleaner. However, if there are a lot of updates within a few milliseconds maybe the server roundtrip is taking too long.

[JimCSuen]

I would try the server update first, thanks!