LiveApp

Origins other than the server's own whose pages may open a live socket, each written scheme://host or scheme://host:port. Empty by default, because the page and its socket come from the same server unless something in between rewrites the Host the browser asked for. That something is usually a proxy, and forwarding the browser's Host is the better fix; this list is for when it cannot. Matching is exact, with no wildcard, since a pattern that admits a subdomain admits whoever controls that subdomain. An entry that is not an origin fails the boot.

Routes the framework itself contributes, appended to whatever table serve is given so that every caller — boot's default, a user's own serve in an overridden boot, dev — serves them without knowing they exist. Empty here: eezo-live's LiveApp overrides it with the live socket and its client script, and EezoApp mixes that in. Appended, so the user's table keeps winning any path both name; they show in the boot listing (they are served, and the listing does not lie) but not in eezo routes, which is the user's table.

The application. The default serves routes on port, which is what makes the minimal application one override and nothing else. Override it for anything more: background work, another setup, no server at all.

The commands this application answers, as first argument :: rest. Nil is program and is answered here, once, so no layer owns it. Each layer writes own orElse super.commands for its own commands, so the later mixin's arms are consulted first.

What dev serves. The umbrella overrides it to run the drift check first and serve the drift page when the check blocks.

The frame every HTML reply comes back in, the derived pages, the login page and the error page included. eezo's plain one unless the application names its own here, which is the one place a frame can be chosen, so that no route has to remember to ask for it.

The request body cap, and the WebSocket text message cap with it.

Where boot's default and the dev command serve.

How the application's own failures are answered: a partial function from what a handler threw to the problem the client sees. What it does not cover, the boundary answers as 500.

What sbt run does on this layer alone: boot, under nothing. The umbrella overrides it to run the same boot under the database layer's lifecycle, the way it overrides devServer. No override here, deliberately: see Dispatch.program.

The key the session cookie is signed with. EEZO_SECRET by default. The sbt plugin's dev loop sets it to one secret per sbt session, so a restart on edit keeps the developer signed in. A run outside that loop with nothing set gets a throwaway announced at WARNING, so that hello runs with no configuration and a deployment that forgot is told. Read once, when serve boots.

The only caller of HttpServer.run: boots the server on this trait's overrides and blocks until it stops. dev turns the listing and the reload client on.

One row per command, for help. Each layer writes own ++ super.usage, and names only the spelling and the description: the columns are help's to lay out, once, over every layer's rows together, so no layer has to guess how wide the others' spellings are.

The route table, usually Routes.table() from the sbt plugin's generated object. Abstract: an http layer is its routes, and an application without any is a mistake.