Hi Marek,
Thanks for looking into this. Last time we looked into it, xterm.js was in the process of a complete rewrite to use canvas instead of the DOM. Their current branch was on very low-maintenance mode. This is why we decided to stay with term.js for a while longer and I did a couple of patches to fix the roughest issues back in October. I agree that xterm.js is the better alternative going forward for the reasons you stated, but I think we should wait for its new branch to stabilize a bit more. Also, it targets quite modern browsers, because its main contributors use it in electron apps. Cheers Lars
On Mon, Jan 8, 2018, at 14:35, Marek Libra wrote:
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 [3] https://github.com/cockpit-project/term.js/commits/master [4] https://github.com/cockpit-project/term.js/commit/2eecc46a9657e0dbcdad5e9b19... [5] https://github.com/patternfly/patternfly-react
-- *Marek Libra*
senior software engineer
Red Hat Czech
[1]
cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel- leave@lists.fedorahosted.org
Links: