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/2eecc46a9657e0dbcdad5e9...
[5]
https://github.com/patternfly/patternfly-react
--
*Marek Libra*
senior software engineer
Red Hat Czech
[1]
_________________________________________________
cockpit-devel mailing list -- cockpit-devel(a)lists.fedorahosted.org
To unsubscribe send an email to cockpit-devel-
leave(a)lists.fedorahosted.org
Links:
1.
https://www.redhat.com