Skizze für eine neue LVP-Architektur
In der Auseinandersetzung mit dem Prototypen zum Java Live Reloading ist eine Idee für eine neue Architektur des Live View Programmings entstanden; die Überlegungen gehen zurück auf eine Diskussion, die Ramon (@RamonDevPrivate) und ich am Montag, den 19.05.2025, geführt haben.
Die grundlegende Idee
(1) Neuausführung des Hauptprogramms, wenn sich ein oder mehr überwachte Dateien ändern (vielleicht per Regex spezifizierbar). Das ist die Idee des Live Reloading.
(2) Printout-basiertes bzw. STDOUT-basiertes Mitteilungsprotokoll an den Server zur Weitergabe an Browser. Im einfachsten Fall werden printouts schlicht direkt an den Browser zur Anzeige durchgereicht. Die index.html sollte standardmäßig Markdown mit LaTeX-Formeln und z.B. die dot-Sprache und andere Boardmittel für das Rendering von Views bereitstellen und dafür textbasierte Protokolle out of the box unterstützen.
(3) Browser teilt Server gewünschte Änderung (in der Regel Ersetzungen) an einer Datei mit; damit wird (high latency) Interaktivität realisiert. Ein Beispiel für low latency Interaktivität sind die SVG-Grafiken mit einem Abfolgeindex, um den Bildaufbau nachvollziehen zu können. High latency Interaktivität läuft über Live Reloading, low latency Interaktivität direkt im Browser.
(4) Falls das Hauptprogramm (oder ein anderes aufzurufendes Programm) während des Aufrufs anhält, um Eingaben über STDIN entgegenzunehmen, kann – in koordinierter Weise – auch medium latency Interaktivität hergestellt werden: Der Browser teilt dem Server eine Eingabe mit, die an den STDIN durchgereicht wird. So kann z.B. auch bei einer REPL-basierten Sprache (Beispiel JShell) mit der REPL direkt kommuniziert werden.
(5) Protokollierung der Historie der Dateiänderungen, mit der Möglichkeit, die Historie zurück- und wieder vorlaufen zu können bzw. den Originalzustand zu restaurieren.
Die Aufzählung kann als Orientierung für eine inkrementelle Implementierung dienen, die den Grundstein einer neuen Architektur für das LVP legt.
Von der Idee zu Architekturkonzepten
Aus (2), (3) und (4) ergibt sich die Generalisierung, dass das Mitteilungsprotokoll verschiedene Trigger, Quellen und Senken haben kann: Als Mitteilungsquellen stellen sich z.B. das STDOUT des ablaufenden Programms und Requests an den Browser über den Port eines verbundenen Clients (in der Regel ein Browsertab) dar. Und als Mitteilungssenken (Ziele oder targets) kommen z.B. das STDIN des ablaufenden Programms und Dateiänderungen infrage. Trigger sind Veränderungen z.B. an Dateien, die die Ausführung eines Programms auslösen. Jede Quelle kann sich gleichermaßen der vom Server implementierten Protokolle bedienen, den Server damit ansprechen und verschiedene Senken adressieren. Diese Verallgemeinerung ist noch auszuarbeiten.
Was das neue Konzept ermöglicht
Das neue Architekturkonzept legt die Grundlage für:
-
ein von Notebook-basierten Programmiermodellen inspiriertes Kompositionskonzept für Programme und Views: mehrere Programmteile (mit eigenständigen main-Methoden) werden zur Ausführung überwacht und steuern verschiedene Anteile zur View bei; in einer noch festzulegenden Art und Weise werden Abhängigkeiten in der Ausführung beschrieben und ausgeführt
-
einen programmiersprachenneutralen Server: durch die printout-basierte Kommunikation kann auch jede andere Programmiersprache wie z.B. Go oder Python zum Live View Programming genutzt werden
-
das Konzept einer funktionalen View-Generierung: dieses Konzept ist der Elm-Architektur entlehnt und ermöglicht einen Replay von Views über die Zeit und damit den zeit-basierten Nachvollzug von high latency Interaktivität.
-
output-basiertes Referenztesten: man kann den textbasierten Strom von Server-Mitteilungen in eine Datei umleiten und gegen eine Referenzdatei prüfen
-
die Idee, eine generierte View als Basis für eine dokumentenbasierte Darstellung (Ausgabe als z.B. PDF oder epub etwa mit einem headless Browser) zu wählen: damit lassen sich z.B. Lehrdokumente oder technische Dokumente erzeugen, in denen der verwendete Code mit den beispielhaften, vom Programm generierten Ausgaben stets übereinstimmt
Skizze für eine neue LVP-Architektur
In der Auseinandersetzung mit dem Prototypen zum Java Live Reloading ist eine Idee für eine neue Architektur des Live View Programmings entstanden; die Überlegungen gehen zurück auf eine Diskussion, die Ramon (@RamonDevPrivate) und ich am Montag, den 19.05.2025, geführt haben.
Die grundlegende Idee
(1) Neuausführung des Hauptprogramms, wenn sich ein oder mehr überwachte Dateien ändern (vielleicht per Regex spezifizierbar). Das ist die Idee des Live Reloading.
(2) Printout-basiertes bzw. STDOUT-basiertes Mitteilungsprotokoll an den Server zur Weitergabe an Browser. Im einfachsten Fall werden printouts schlicht direkt an den Browser zur Anzeige durchgereicht. Die
index.htmlsollte standardmäßig Markdown mit LaTeX-Formeln und z.B. die dot-Sprache und andere Boardmittel für das Rendering von Views bereitstellen und dafür textbasierte Protokolle out of the box unterstützen.(3) Browser teilt Server gewünschte Änderung (in der Regel Ersetzungen) an einer Datei mit; damit wird (high latency) Interaktivität realisiert. Ein Beispiel für low latency Interaktivität sind die SVG-Grafiken mit einem Abfolgeindex, um den Bildaufbau nachvollziehen zu können. High latency Interaktivität läuft über Live Reloading, low latency Interaktivität direkt im Browser.
(4) Falls das Hauptprogramm (oder ein anderes aufzurufendes Programm) während des Aufrufs anhält, um Eingaben über STDIN entgegenzunehmen, kann – in koordinierter Weise – auch medium latency Interaktivität hergestellt werden: Der Browser teilt dem Server eine Eingabe mit, die an den STDIN durchgereicht wird. So kann z.B. auch bei einer REPL-basierten Sprache (Beispiel JShell) mit der REPL direkt kommuniziert werden.
(5) Protokollierung der Historie der Dateiänderungen, mit der Möglichkeit, die Historie zurück- und wieder vorlaufen zu können bzw. den Originalzustand zu restaurieren.
Die Aufzählung kann als Orientierung für eine inkrementelle Implementierung dienen, die den Grundstein einer neuen Architektur für das LVP legt.
Von der Idee zu Architekturkonzepten
Aus (2), (3) und (4) ergibt sich die Generalisierung, dass das Mitteilungsprotokoll verschiedene Trigger, Quellen und Senken haben kann: Als Mitteilungsquellen stellen sich z.B. das STDOUT des ablaufenden Programms und Requests an den Browser über den Port eines verbundenen Clients (in der Regel ein Browsertab) dar. Und als Mitteilungssenken (Ziele oder targets) kommen z.B. das STDIN des ablaufenden Programms und Dateiänderungen infrage. Trigger sind Veränderungen z.B. an Dateien, die die Ausführung eines Programms auslösen. Jede Quelle kann sich gleichermaßen der vom Server implementierten Protokolle bedienen, den Server damit ansprechen und verschiedene Senken adressieren. Diese Verallgemeinerung ist noch auszuarbeiten.
Was das neue Konzept ermöglicht
Das neue Architekturkonzept legt die Grundlage für:
ein von Notebook-basierten Programmiermodellen inspiriertes Kompositionskonzept für Programme und Views: mehrere Programmteile (mit eigenständigen main-Methoden) werden zur Ausführung überwacht und steuern verschiedene Anteile zur View bei; in einer noch festzulegenden Art und Weise werden Abhängigkeiten in der Ausführung beschrieben und ausgeführt
einen programmiersprachenneutralen Server: durch die printout-basierte Kommunikation kann auch jede andere Programmiersprache wie z.B. Go oder Python zum Live View Programming genutzt werden
das Konzept einer funktionalen View-Generierung: dieses Konzept ist der Elm-Architektur entlehnt und ermöglicht einen Replay von Views über die Zeit und damit den zeit-basierten Nachvollzug von high latency Interaktivität.
output-basiertes Referenztesten: man kann den textbasierten Strom von Server-Mitteilungen in eine Datei umleiten und gegen eine Referenzdatei prüfen
die Idee, eine generierte View als Basis für eine dokumentenbasierte Darstellung (Ausgabe als z.B. PDF oder epub etwa mit einem headless Browser) zu wählen: damit lassen sich z.B. Lehrdokumente oder technische Dokumente erzeugen, in denen der verwendete Code mit den beispielhaften, vom Programm generierten Ausgaben stets übereinstimmt