Push ServeSession to the start

ARCHITECTURE.md

@@ -6,27 +6,25 @@ This document is a "what the heck is going on" level view of Rojo and the codeba
 
 ## Overarching
 
-Rojo is divided into two main pieces: the server and the Studio plugin. The server runs with access to your filesystem (whether it be via the terminal, the visual studio code extension, or a remote machine), with the Studio plugin acting as its main client.
+Rojo is divided into several components, each layering on top of each other provide Rojo's functionality.
 
-When serving a project, the server gathers data on all of the files in that project, puts it into a nice format, and then sends it to the plugin. Then, when something changes on the file system, it does the same thing for only the changed files and sends them to the plugin.
+At the core of Rojo lies [`ServeSession`](#servesession). As the name implies, it contains all of the components to keep a persistent DOM, react to events to update the DOM, and serve the DOM to consumers.
 
-When the plugin receives a patch from the server (whether it be the initial patch or any subsequent ones), the plugin reads through the patch and attempts to to apply the changes described by it. Any sugar (the patch visualizer, as an example) happens on top of the patches received from the server.
+Most of Rojo's uses are built upon `ServeSession`! For example, [`SourcemapCommand`](#sourcemapCommand) uses `ServeSession` to generate the DOM and read it to build the `sourcemap.json` file.
 
-## Server
+### The Serve Command
 
-Rojo's server component is divided into a few distinct pieces:
+There are two main pieces in play when serving: the server and the Studio plugin.
 
-- The web server
-- The CLI
-- The snapshotting system
+The server runs a local [`LiveServer`](#liveserver) with access to your filesystem (whether it be via the terminal, the visual studio code extension, or a remote machine). It consumes a `ServeSession` and attaches a web server on top. The web server itself is very basic, consisting of around half a dozen endpoints. Generally, [`LiveServer`](#liveserver) acts as a middleman with the bulk of the work is performed by either the underlying `ServeSession` or the plugin. 
 
-### The CLI
+To serve a project to a connecting plugin, the server gathers data on all of the files in that project, puts it into a nice format, and then sends it to the plugin. After that, when something changes on the file system, the underlying `ServeSession` emits new patches. The web server has a `api/subscribe` endpoint where the plugin [long polls](https://en.wikipedia.org/wiki/Push_technology#Long_polling) to receive the patches from the server and apply them to the datamodel in Studio.
 
-The Command Line Interface (CLI) of Rojo is the only interface for the program. It's initialized in `main.rs` but is hosted in `src/cli`.
+When the plugin receives a patch it reads through the patch contents and attempts to to apply the changes described by it. Any sugar (the patch visualizer, as an example) happens on top of the patches received from the server.
 
-Each command for the CLI is hosted in its own file, with the `mod.rs` file for the `cli` module handling parsing and running each command. The commands are mostly self-contained, though may also interface with Rojo's other code when necessary.
-
-Specifically, they may interface with the web server and snapshotting system.
+### The Sourcemap Command
+### The Build Command
+### The Upload Command
 
 ### The Snapshotting System
 
@@ -42,12 +40,6 @@ Inquiring minds should look at `snapshot/mod.rs` and `snapshot_middleware` for a
 
 Because snapshots are designed to be translated into Instances anyway, this system is also used by the `build` command to turn a Rojo project into a complete file. The backend for serializing a snapshot into a file is provided by `rbx-dom`, which is a different project.
 
-### The Web Server
-
-Rojo uses a small web server to forward changes to the plugin. Once a patch is computed by the snapshot system, it's made available via the server's API. The plugin is requesting patches regularly using a technique called [long polling](https://en.wikipedia.org/wiki/Push_technology#Long_polling) to receive the patches from the server and apply them to the datamodel in Studio.
-
-The web server itself is very basic, consisting of around half a dozen endpoints. The bulk of the work is performed by either the snapshot system or the plugin, with the web server acting as a middleman.
-
 ## The Plugin
 
 This section of the document is left incomplete.
@@ -60,12 +52,43 @@ Rojo has many data structures and their purpose might not be immediately clear a
 
 To learn more, read about [`memofs` architecture](crates/memofs/ARCHITECTURE.md).
 
+### LiveServer
+
+LiveServer underlies the [`serve` command](#the-serve-command) and provides the web server which clients (such as the plugin) can use to interface with [`ServeSession`](#servesession).
+
+There's two parts to the API, the UI and the API clients use.
+
+The UI provides information about the current [`DOM`](#rojotree) has, including metadata. It also shows the project name, up-time, and version its Rojo is on.
+
+The API provides a simple JSON protocol to interact with and receive changes from the underlying [`ServeSession`](#servesession). Checkout the [`api.rs` file under the web module](src/web/api.rs) to learn more.
+
 ### ServeSession
 
+The linchpin of Rojo. It contains all of the required components to serve a given project file.
+
+Generally, to serve means:
+
+- Rojo maintains a DOM and exposes it to consumers;
+- Rojo is able to accept events to cause changes to the DOM;
+- Rojo is able to emit changes to the DOM to consumer.
+
+It depends on:
+
+- `RojoTree` to represent the DOM;
+- `Project` to represent your root project file (e.g. `default.project.json`);
+- [`Vfs`](#vfs) to provide a filesystem and emit events on changes;
+- [`ChangeProcessor`](#changeprocessor) to process filesystem events from `Vfs` and consequently update the DOM through the [snapshotting system](#the-snapshotting-system);
+
+It also provides an API for the higher level components so it can be used with the outside world.
+
+- There is a `MessageQueue` of changes applied to the DOM.
+- There is a channel to send changes to the `ServeSession` and update the DOM.
+- And a `SessionId` to uniquely identify the `ServeSession`.
+
+All of the public interfaces via CLI of Rojo are implemented using `ServeSession`.
+
 ### ChangeProcessor
 
 ### RojoTree
 
-### LifeServer
-
 ### InstanceSnapshot