# FS Display Server

By day, I used to do this …

## Traditional FS

### eRemoteCtrl fixes some of these but...

- Main display views the log
- But not all errors go into the log, especially critical errors
- Silenced messages do go into the log
- FS is still attached to an X server — it crashes or you logout, the FS goes with you
- no `fs.prompt` and `autoftp` support

## Field System display server

### Design goals

- Prevent unintentionally exits of FS by making the core part in the background
- Multiplex the display rather than the log
- Simple interface — ideally operators won't even notice the difference
- Maintain compatibility for stations code
- Possibility different types of clients — text-only and browser based clients in mind
- `fs.prompt` and `autoftp` support

### Non-goals

- Authentication + Access control — leave to be handled by OS or clients
- Special clients — first client is like any other

## Display Server FS

## Implementation

- fsserver acts like a terminal multiplexer (eg `screen` or `tmux`)
- fsserver runs the core FS programs in a "window": a pseudoterminal with the output streamed to the client(s)
- fsclient instances run the GUI FS programs
- other programs opened in xterm, eg autoftp, can be opened in separate windows and streamed to the clients
- all communication is performed via the `nng` library, which can transparently use websockets, unix, or tcp sockets.
- current implementation is using unix sockets for local only access
- `JSON-RPC` over a nng socket is used for commands
- Shipped in 9.13.0, disabled by default

## Handling `fs.prompt`

### When `fs.prompt` called from a child of FS in server mode

1. an `fs.prompt` shim is called rather than real `fs.prompt` (by adding to `PATH`)
2. `fs.prompt` shim messages `fsserver` with message string and whether to inject "cont" to fs
3. `fsserver` broadcasts the prompt properties to all clients with a unique ID
   interpretation is left up to client; reference client uses real `fs.prompt`
   future clients may handle differently
4. when one client `fsserver` broadcasts the prompt properties to all clients with a unique ID

## Handling `fs.prompt`

## `autoftp` and other terminal programs

- `autoftp` is started by boss in an xterm
- similar to `fs.prompt`, an xterm shim is adding to `PATH` by children `fsserver`
- this then starts the arguments to xterm in an `fsserver` window
- `fsserver` windows are non-interactive, and we don't (like to) break station code
- so we whitelist only known safe programs. Items not on the whitelist get the real xterm

- Shipped in 9.13.0, and 9.12.12!
- Plans for web and TUI clients
- Please give it a go!

# End!