<div dir="ltr"><div dir="ltr">>At some point there was talk of moving the html5 stuff over to xterm, to <br>>support more encoding styles, but I don't think anyone has started that <br>>work.<br><div><br></div><div>I've started and am currently working on switching from hterm to xterm at </div><div>the moment, as an update. </div><div><br><a href="https://github.com/xtermjs/xterm.js/">https://github.com/xtermjs/xterm.js/</a><br></div></div></div><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 4, 2018 at 7:29 PM Ed Tanous <<a href="mailto:ed.tanous@intel.com" target="_blank">ed.tanous@intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 09/04/2018 05:07 PM, Emily Shaffer wrote:<br>
> I wonder if there's a different and more useful way we can provide the <br>
> console scrollback. Thinking about this, it's not just a GUI issue, <br>
> right - we deliver our console over TCP to a client elsewhere and would <br>
> have the same dedupe issues if we needed to start providing backlog.  <br>
<br>
Correct, this isn't _just_ a webui issue.  It happens on all the <br>
available interfaces (SSH, HTML5, and obmc-console-client)<br>
<br>
> Speaking with almost no experience implementing server-side sockets, is <br>
> it possible for us to keep that ring buffer in the console socket as well?<br>
<br>
obmc-console already keeps a ring-buffer style log of all the previous <br>
characters.  The easiest to implement answer, which is probably good <br>
enough for most cases, would be to simply make obmc-console barf up the <br>
saved console log ring buffer when any new client connects.  This will <br>
have problems if your control characters have run off the end of the <br>
buffer, and the console would appear to quickly replay your last X <br>
characters worth of interactions, which isn't desired.<br>
<br>
I could also imagine a case where this isn't the desired behavior if <br>
you're using automation to interact with SSH/SOL, so it might need to be <br>
selectable by the client or have some kind of reasonable workaround.<br>
<br>
I'm fairly certain there's some buffering routines we can steal from <br>
screen and/or tmux that would just track the screen state, and blast the <br>
minimum character sets to each client on reconnect, but I haven't looked <br>
into it too deeply.<br>
<br>
> <br>
> I'm also interested in how you all are getting the console over to <br>
> webui.  Is it delivered via Redfish? (This is totally different from <br>
> what we are doing, so apologies if that's a fundamental question, but <br>
> I'm certainly keen to know now :) )<br>
> <br>
<br>
Today the console is being dumped to a dumb websocket that just mirrors, <br>
encodes, and encrypts the traffic to the browser using websocket frames. <br>
  On the browser side, we pipe that console into hterm, which turns the <br>
raw characters into a reasonably correct console.<br>
<br>
<a href="https://chromium.googlesource.com/apps/libapps/+/master/hterm" rel="noreferrer" target="_blank">https://chromium.googlesource.com/apps/libapps/+/master/hterm</a><br>
<br>
At some point there was talk of moving the html5 stuff over to xterm, to <br>
support more encoding styles, but I don't think anyone has started that <br>
work.<br>
</blockquote></div>