The DomTerm architecture is split into front-end and back-end, each of which could have different implementations.
┌─────────────────────────────────────┐ Front-end │ Window, input devices (keyboard) │ ├─────────────────────────────────────┤ │ Browser engine (runs terminal.js) │ ├─────────────────────────────────────┤ │ Communication stub │ └-────────────────────────────────────┘ 🠉 connection (optional network) 🠋 ┌─────────────────────────────────────┐ Back-end │ Communication stub │ ├─────────────────────────────────────┤ │ Application (session) │ └─────────────────────────────────────┘
The back-end runs the actual applications that the user cares about. An application can be a shell process running under a PTY, or a custom application, such as a programming language run-time or a chat server.
A session is a specific application instance (a process).
A window is a top-level window or a sub-window (tile or tab)
in a DomTerm front-end.
A session window is one that interacts with a session.
A non-session window is created by a
that do not create or connect to sessions, such as
A connection communicates between a window (front-end) and the back-end, and thence usually to a specific session. The connection usea a byte-stream protocol that is based on the xterm protocol: text and escape sequences from the application to the front-end; keystrokes and encoded events sent the other way. These data streams can be layered on top of other protocols, such as WebSocket, pipes, or ssh. Using WebSocket is convenient because it is portable and is built in to modern browser engines.
A (domterm) server process is a kind of back-end
that can manage multiple sessions, commands, and connections.
It can also open windows in browser engines.
It normally runs in the background,
as one process for a given user and host (computer),
though you can override that if you use the
The server listens for requests on the command socket.
A setting is a pair of a setting name
and setting value that controls how DomTerm behaves.
The global settings are defined in a configuration
file normally named
The local settings can be specified on the
line, and apply to the current command, current session, or current window.
The local settings take priority over the global setings.