[Feature Request] Run Lite remotely and access it through the browser

[ruanchaves]

cdr/code-server Run VS Code on any machine anywhere and access it in the browser.

I would like to run Lite on an Amazon EC2 instance ( or any other remote server for that matter ) and access it through the browser on my old laptop or my smartphone.

This has already been done for vscode ( see above ) but it requires slightly more than 1GB of RAM, so it is not possible to run it on free tier EC2 instances.

As Lite is mean to be lightweight, I think that would be an excellent use case for this text editor.

[rxi]

This isn't something I will be adding personally, additionally, as I haven't looked closely at the linked project, I don't know how much of a role the fact that VS code is based upon electron plays in something like this. I imagine implementing something similar for lite may take more code than lite itself currently consists of -- anyone is welcome to try their hand at implementing this, though such functionality won't be merged into lite's core.

[Tmpod]

Doing that with VSC is feaseable because it is already built with HTML/CSS/JS with Electron. Doing this for lite would imply reimplementing all the system drawing functions so that they translate to browser stuff, plus a lot of work on the server side of things too.

Maybe this could be closed @rxi? Even if someone ends up making something like this, it won't be merged onto the upstream, so it's just clogging up the issue tracker :P

[MaD70]

This could be done (it's a suggestion for volunteers, I'm not saying the original author of lite must do it) with much less effort than what is being suggested here, mimicking what remote control software like VNC usually do (but for a single application): capture what is changed respect to the previous frame (the infrastructure is there, see rencache.c) and send it to the client (as compressed bitmaps). The other ingredients could be:

1. real-time, lossless compression/decompression libraries (compression on the server, in C, and decompression on the client, in Javascript). Note that this is probably not strictly necessary nowadays everywhere there is fast Internet access, but it is useful to save on bandwidth (mobile users). See, for example: heatshrink, Zstandard (has a JavaScript port compiled with Emscripten), Brotli (has a Javascript decoder but apparently is supported natively by modern browsers), and so on. Considering that lite would transmit mostly glyphs, a specialized and simpler compression algorithm could be better;
2. a tiny, embeddable web/WebSockets server (this should add no more that some tens of KiBs to the lite executable). See, for example: SHTTPD, Lwan, Mongoose, Minnow Server, and so on;
3. for the client part:
   • a landing html page with an HTML5 Canvas where to draw (with Javascript) what is being sent (via WebSockets) from the server to client (the Javascript decompression library is used here);
   • a bit of Javascript (again, in the previous html page) to intercept keyboard key presses and mouse movements to send (via WebSockets) from client to server. See, for example, the noVNC project for some inspiration and perhaps reuse of some source code (especially the HTML/Javascript part regarding Canvas/WebSockets). Note that it uses the Remote Framebuffer Protocol (RFB) which is probably overkill for this application, a more simple protocol should suffice;
4. a way to authenticate user connections to the lite editor server.

An halfway step for debugging purpose could produce a feature useful in itself: saving an editing session to a file, as a "video" (an easy format, perhaps ad-hoc, should be chosen to minimize complexity).

N.B.: the editor server doesn't need to draw to the screen and so it doesn't need SDL: a configuration option could be added to compile lite without linking to SDL (this should be easy if and only if it doesn't use SDL for off-screen operations; I'm not familiar with Lua so I mostly ignored Lua sources in the editor).