The support for remote connections is a relatively thin layering on top of ssh. When you type:
domterm user@host command
it basically translates to:
ssh user@host domterm --browser-pipe command
All connection setup and logging in are handled by ssh.
If you do a command like:
domterm user@host status
this will run domterm --browser-pipe status on the host.
In this case the --browser-pipe option is irrelevant:
Output from the command will be printed on standard output
which ssh then sends back to the local domterm,
which prints in on the local terminal.
If the command creates a window, things get more interesting. For example:
domterm --qt user@host attach :1
Again, ssh will execute domterm --browser-pipe attach :1
on the remote host. This will attach to existing session 1.
Then, when domterm would normally create a a new window,
it sees the --browser-pipe. It prints a special escape character,
which is sent back to the local domterm server, which switches
from command-proxy mode to display-proxy mode, opening up a window.
(A Qt window because of the --qt option.)
In display-proxy mode, characters and other events from the window
are written to the input of the ssh process,
while output from the remote user process are sent
via the remote domterm server over ssh to the local domterm server,
which displays them in the window.
┌─────────────────────────────────────┐
Front-end │ Window, input devices (keyboard) │
├─────────────────────────────────────┤
│ Browser engine (runs terminal.js) │
└-────────────────────────────────────┘
🠉
WebSockets connection (local)
🠋
┌─────────────────────────────────────┐
Local │ Proxy (local end) │
back-end ├─────────────────────────────────────┤
│ Ssh client (local session) │
└-────────────────────────────────────┘
🠉
ssh connection (network)
🠋
┌─────────────────────────────────────┐
Remote │ Proxy (remote end) │
back-end ├─────────────────────────────────────┤
│ Application (session) │
└─────────────────────────────────────┘
(Compare with diagram at Terminology and Concepts.)