Xterm.js: demo resize issue

[jerch]

The emulator demo doesnt seem to propagate resize back to the pty which leads to weird behavior when you input something lengthy (pty sends 'r' and you just overwrite the current line). It also prevents commands like top from using the whole container.

[parisk]

Thanks for reporting. This will need some work to be implemented. Right now the websocket stream exchanges raw bytes with the back-end pty.

We will either have to change the way the stream works in order to include control commands like resize or create an HTTP endpoint for this particular reason. The latter needs more work to be done (including identifying the current pty), but IMO is the best solution.

[akalipetis]

We could also follow the approach of takluyver/terminado, which exchanges messages with specific commands. Also, features a Terminal creation API and I think is based on Term.js.

Alternatively, we could check if they're interested in switching to Xterm.js and then use that as a more complete demo.

[jerch]

Hmm no clue which path to take here, IMO the problem can be reduced to the question whether the websocket is solely used as a transport layer for the pty pipe or if it can transport any emulator related data. The latter would require to introduce some structured data layer over the websocket while the first would need to establish a side communication with the backend (and some type of emulator lock until the side communication got processed).
From a point of functionality separation and performance the side communication might be better as it would avoid additional parsing of the pty stream all the time.

[parisk]

I think we should stick with the websocket serving as a transport layer only as well. This way we are able to test the attach addon also, through the demo and it will keep the transmission throughput to the maximum with the current means.

[akalipetis]

Btw, @jerch given that Xterm.js supports add-ons, we could create this implementation as a separate add-on which users could use. This way, we can keep the core functionality of the project here which should cover most of the use cases.

Creating such as add-on with the attach add-on as a reference should not be that hard.

[jerch]

Although all downvoted the websocket protocol idea (including myself), here is a quick hack with it (was just easier to implement partly hardcoded :wink:). The impact on the throughput is to my own surprise neglectable.