Infinite history log on server

[hediet]

I am building a tool (in TS) that runs terminal applications for which I want to provide a browser-based live terminal view with support for colors/progress bars and all other terminal features. However, I want to load the history of the terminal view dynamically from the server as the user scrolls up (the terminal application is usually started way before the uses opens the webview und thus has some history).

It seems like xterm.js seems to be a good fit for the terminal view.

However, xterm.js parses the ANSI escape sequences on the client which makes it very hard to dynamically load the history. Ideally, the server only stores the history buffer and not all the ANSI escape sequences that make up the buffer when applied in order.

Is this scenario possible with xterm.js's architecture?

For further clarification:
Just storing all the ANSI escape sequences on the server and sending them all to the (xterm-based) client when the client initially connects is not an option, as there can be arbitrary many ANSI escape sequences that are not relevant for the current view and history anymore. E.g. a spinner or a progress bar.

I also already asked this question on SO but didn't get any answer.

[Tyriar]

We've talked about this a bit in #1507, the latest thinking is to not pursue splitting up the core/ui portions of xterm across different machines/processes, at least at the same time as the current big architectural changes being made as that's a beast to tackle on its own.

It might be possible eventually, but for now we're optimizing for the case where xterm.js entirely on the client and trying to get the project in full TypeScript strict mode and untangling some of the interdependencies between components. We're also exploring flow control right now (#2122) which solves a lot of the problems with running the full xterm.js on the client as it will pause the backing process to allow the client to catch up.

[hediet]

Thanks for your fast answer ;)
What would you suggest me to do? I would otherwise implement my own solution / try to extract things from xtermjs.

[Tyriar]

With flow control you might be able to work with vanilla xterm.js, that will block the process from proceeding if the client falls too far behind. I don't know why you say it's not an option, but I know the problem fairly well and it's not that big of an issue when the process is remote.

I'd suggest looking into that before trying to fork or something, I expect you would diverge a lot from xterm.js and not be able to pull in valuable upstream updates if you did this.