Hi,

I'm considering exposing the VM consoles we already have in Cockpit for their reuse by other projects, like ManageIQ or oVirt's VM Portal.

One way to do it is moving them under the patternfly-react library [5], partially involving the patternfly community in their later development (and probably even design).

The transition would be implemented step-by-step, starting with the serial console.
The idea is to externalize VM serial console and underlying Terminal component and "reuse" them back in Cockpit.
To do so, it makes sense to move from the term.js-cockpit fork to the maintained xterm.js [1], successor of [2].

Once this is done, other use of the term.js-cockpit will be similarly replaced to depend just on the single [1].

Benefits for Cockpit:
- use of upstream-maintained library
- leverage last (almost) 2 years of the xterm.js development
- be aligned with other related projects on the design level (and drive it!)

Disadvantages:
- quite a lot of work in backporting term.js-cockpit patches to xterm.js
- risks - bugs in already stabilized features might/will appear

I've already implemented POC proving this is feasible and the components can provide reasonable wrapping/API.

There's still a lot of work to be done, starting with porting of [3] to [1].

So, here's the question: is this something what makes sense even for Cockpit-maintainers?

If so, is there already any experience (good/bad) in merging some of the [3] into any successor of [2]? The most important and maybe debatable seems to be [4].

Thanks for opinion,
Marek

[1] https://github.com/xtermjs/xterm.js
[2] https://github.com/chjj/term.js

--

Marek Libra

senior software engineer

Red Hat Czech