The Quest Protocol - mr-martian/quest-editor GitHub Wiki

Summary of Past Discussions

The central operating principle of the Quest System is decoupling or weak coupling via protocols.

There is currently a discussion under way concerning the protocol as well as the design process of the protocol. From that discussion, a few conclusions can be drawn thus far:

  1. We should attempt to design the protocol correctly the first time. That will be easiest in the long run.
  2. The protocol, like much of the Quest System will be bespoke to Quest, borrowing only concepts from similar protocols. Initially, we investigated using a modern display protocol, specifically Wayland, as the goals are somewhat similar. But fundamentally, Wayland is solving a different problem, even if it looks similar.
  3. The protocol is primarily for communication between Quest Core and Quest Shells.
  4. The protocol essentially defines the capabilities of a Quest Shell. All input events (mouse, keyboard, trackpad, touchscreen), and all output effects (sound, video, etc) have 1st class support in the protocol.

Discussion yet to be had:

a. Backwards and forwards compatibility? Should the protocol be backwards compatible for all history, or should we adopt a major/minor versioning system, locking together eras of versions of Core and Shell? Should the protocol support feature presence arbitration to determine if either a shell or a version of Core doesn't support features of one or the other, but find some common ground so that the system will at least be usable?

b. Should the protocol be network transparent so Quest Core may operate on a server and be accessed either via LAN or WAN?

c. does Core hold some shell state internally, or only send layout commands to Shell to process, and then the protocol has a querying feature to find out the current state of shell?

Todo: brainstorm then define the state or kind of state that Shell is to maintain.

Rational

Quest Core handles all non-display processing in order to keep things simpler in the frontend. Frontend work is typically quite onerous, and so separating these two will likely increase system stability, as well as improve overall code comprehensibility.

Specification (WiP)

glossary

  • frame : a series of bytes that contain a message or part of a message of a protocol.
  • message/packet : a single complete transmission from one system component to another. It might be contained in a single frame or multiple frames.
  • event : a stimulus to or from core denoted by a stream of bytes.
  • scan code : an integer generated by keyboard hardware when the user presses a key
  • key code : similar to scan code, but has some standardized meaning associated with it, e.g. "key CONTROL" or "key A" provided by the window/session manager.

Overview

The quest protocol is an application layer protocol that enables messaging with these directionalities:

  • Core to Shell
  • Shell to Core
  • One instance of Core to another instance of Core

Each of these may be either local or over a network.

Every feature of a shell is represented in the Quest Protocol.