why is bin/domterm needed?
albertz opened this issue · comments
Maybe this is also just an issue of the documentation, and can be fixed by explaining that.
But I fail to understand why we need the native bin/domterm at all. E.g. for Electron. Why would running electron directly not work?
If the answer is that bin/domterm starts some server which runs in the background and the JS code (where ever it is run, in Electron, Firefox, Chrome, etc) somehow communicates with that (I'm just guessing, I have no idea if this is the case; as said, it would be nice to make this clear in the doc):
Would it be possible to rewrite e.g. the Electron backend that this is not needed, and it all runs directly in the same Electron process? (Or why would that not be possible?)
"Why would running electron directly not work?"
The electron command would still would still need some options to specify the DomTerm application scripts, so regardless you'd want at least small domterm shell script. More importantly, domterm can be run without Electron: For example if you use the Firefox web browser, Electron is not needed or used at all.
"If the answer is that bin/domterm starts some server which runs in the background and the JS code (where ever it is run, in Electron, Firefox, Chrome, etc) somehow communicates with that"
Precisely. I added a small about of text at the beginning of the home page and also the "The DomTerm command" page. Hopefully that helps.
"Would it be possible to rewrite e.g. the Electron backend that this is not needed, and it all runs directly in the same Electron process? (Or why would that not be possible?)"
Possibly. I'm not an Electron expert. There are a lot of low-level things that the domterm application does: start http and web sockets servers; start and manage sessions (user processes); read and watch the .domterm/settings.ini file; command handling. Some of these might be as easily or more easily written in JavaScript and Electron packages; some might be require using "native" code. Using C makes the code portable and efficient. I don't see any major benefit to use Electron for the server. (I've considered re-writing the server in Rust at some point, but not anytime soon.)
Ok, thanks for the clarification. About the last point, i.e. having it directly in Electron: I guess my motivation is mostly usability. E.g. Terminal / iTerm on MacOSX, or Konsole / Gnome-Terminal etc on Linux, it's just a single click and you get a window with the shell. This is what I would like to have with DomTerm. It's maybe just a question of how you bundle it in a nice way, and then provide a simple bundle to download. E.g. you could all bundle it together in an Electron app, which then can also provides something like auto-update, and crash reports, etc, and users can just download that bundle and use it directly.
Maybe you are not using MacOSX. So you could not create that OSX bundle. But that's my point with removing as much native code as possible. (And probably there are NPM packages for most things which you need.) I think it's easy to create an Electron bundle for all major platforms then. (Maybe, at least that is what I would imagine / hope. I'm also not an Electron expert.)
I'm not sure how important it is for you about how many other people are using this, or if this is just a toy project. But I think if you want that console apps starting using some of DomTerm features / the extended escape codes, this will only happen when DomTerm becomes more widely used. Or if you work together with GraphTerm (or other projects) and agree on a common standard (which would be anyway the best thing to do). I'm currently thinking about adding some support to my app (e.g. for automatically folding away some logging output, #54), but not really sure. If DomTerm is just a toy project of yours, then this probably does not make much sense. But I actually think this could have some great potential.
"Konsole / Gnome-Terminal etc on Linux, it's just a single click and you get a window with the shell."
That works. See the "Adding domterm or qtdomterm to the desktop" section in https://domterm.org/Tips.html .
"It's maybe just a question of how you bundle it in a nice way, and then provide a simple bundle to download. E.g. you could all bundle it together in an Electron app, which then can also provides something like auto-update, and crash reports, etc, and users can just download that bundle and use it directly."
That may be worth considering. But notice there are lots of people who despise Electron apps (see many Hacker News discussions). (Especially among the type of people more likely to terminal emulator.) So there is an advantage to not depend too much on Electron. One plan is do a "domterm proxy server": Instead of ssh to a remote computer, you'd ssd to a (headless) domterm proxy. This can give you sessions that survive network failure, multi-headed use, etc. One can probably do this sort of things with Electron, but it's not its strong suit. I'm more leaning towards at some point re-writing the server code to Rust (but not anytime soon). Though if someone were to re-write the server part as an Electron app, I'd probably be ok with it.
It might be convenient to let people download domterm bundled as an electron app. I don't know how difficult it would be to write a node wrapper around the domterm server, but assuming it's not too difficult, that may make lot of sense.
I have an experimental "pure-Electron" DomTerm in the electron-nodepty directory. See this page about status and limitations. It needs some polishing in terms of build procedure/instructions but works tolerably well. If requested, I'll prioritize improving this.