Terminology and Concepts

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 front-end runs the actual terminal emulator. It manages the display and user interaction. It runs in a browser engine, which is the core part of a web browser that loads and displays web pages, and processes JavaScript. For DomTerm you can use a window or tab in a general-purpose browser (such as Firefox or Chrome), or you can use a framework for writing applications that provide a browser engine for the user interface (such as Electron, Qt, or JavaFX).

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 domterm commands that do not create or connect to sessions, such as domterm browse or domterm view-saved.

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 --socket-name option. 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 settings.ini. The local settings can be specified on the domterm command line, and apply to the current command, current session, or current window. The local settings take priority over the global setings.