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