\documentclass{article}
\usepackage{ulem}
\usepackage{graphicx}
\usepackage{hyperref}
\pagestyle{headings}
\begin{document}
\part{Bootstrapping an environment}
Horde's registry and bootstrapping predates composer, composer autoloader and most modern conventions. It is not helped by being super flexible in almost every aspect.
Bootstrapping is the order in which (a necessary part of) the Horde application environment is set up before actually running useful code. The current process is hard to understand and reason about.
With modern standards and concepts, a basic service or app need not carry around baggage from assumptions that may be entire irrelevant.
For example, the horde base app
\section{H5/Classic}
Not necessarily in that order. Even getting the order right is non-trivial.
\begin{itemize}
\item Calling the core from the page, service endpoint or CLI
\item setting up preliminary autoloading
\item Setting up some fundamental constants, including guessing some paths.
\item Lots of chicken/egg things
\item setting up a preliminary (opinionated) selection of Dependency Injection keys for the Horde\textbackslash\{\}Injector DI
\item setting up all sorts of scary globals
\item finding installed applications
\item finding config for installed applications
\item finding out if or if not snippets matching the current domain vhost should be applied
\item Setting up even more autoloading for the current app
\item Setting up filesystem locations and web-visible paths (possibly domains, too) for apps and the horde base app, themes, javascript, templates ...
\item Session handling, based on config
\item determine if the current session is administrative or has a certain permission
\item Language handling
\item Setting up fundamental services like auth, logging
\item Everything happens live on request
\end{itemize}
\section{Standalone/Web}
Three stages:
\subsection{Early stage}
\begin{itemize}
\item Web server calls entrypoint.
\item Composer autoloader first. One load to rule them all.
\item Feed the DI with the bare minimum for routing purposes. (Less is better)
\item Load cached list of relevant apps/services that expose routes. If it does not exist, assemble it.
\item some primitive early error handling
\end{itemize}
\subsection{Routing stage}
\begin{itemize}
\item Load routes
\item Assemble request object
\item match request with routes
\item call stack associated with route
\item Perform PSR7/15 dance
\item handle route-not-found / default route
\end{itemize}
\subsection{Middleware/Controller stage}
\begin{itemize}
\item authentication, if they want it
\item permission handling, if they want it
\item prefs handling, if they want it
\item login to backing services, if they want it
\item handle any errors
\end{itemize}
\section{Modern/CLI}
TBD
\subsection{Random considerations}
\begin{itemize}
\item Apps (and services) are basically groups of routes that share a codebase and a subdomain + webroot combination.
\item Something standalone would not need registry, but would need (top level) routing.
\item Is Registry is just an added value top layer router that houses per-app / per-service sub routers?
\item Registry Config MAY depend on host of the request. To keep it lean, vhost is "always on". Parsing a config to find out if you should load a file (or ignore if missing) is always more expensive than just doing it.
\item Registry Config determines webroots for apps, Routes depend on it. Setting up registry should be fast with as few side effects as possible. It should not imply heavy lifting, setting up DB/IMAP or other expensive connections.
\item But we do not need heavy weight app init upfront.
\item For routing setup, we do not care if the app in question is disabled, inaccessible for the current credentials or anything. This should be handled by some middleware.
\item Each app/service has its endpoint, identifying a first routing level and at least some registry-defined routes for URI generation (js, themes, templates, appwebroot)
\item We want to be able to generate routes towards other apps inside this installation.
\item nested route groups can be resolved to one single set of combined routes.
\item nested route groups can have default middleware stacks at each level. These can be merged to a single middleware stack, including the route's handler, middleware or stack
\item nested route groups can have a catchall on each level.
\item How to attach / autogenerate useful API docs (like openapi) from routing information?
\item Are verbs part of the routing or should they be filtered by a middleware?
\item URI parameter constraints.
\item Collecting the routes into one consumable RoutesCollection should be separate from consuming the RoutesCollection. Collect at install/config time and save the result.
\item Routes Matching should produce a MatchedRoute exposing useful information but should not call/dispatch the resulting stack.
\item The router must allow to pass through some information it is not interested in by itself or does not recognize
\end{itemize}
\end{document}