mi/werkbaum
1
0
Fork 0
Code Issues Pull Requests 3 Actions Packages Projects Releases Wiki Activity

docs: Feed nur im sichtbaren Tab (D76-Nachtrag 1)

Browse Source 
Der Zielserver bietet kein HTTP/2, also gilt das Browser-Limit von sechs
Verbindungen je Herkunft - ein dauerhaft offener Long-Poll je Tab engt bei
mehreren Tabs alles andere ein. Der Feed schliesst deshalb bei
visibilitychange und holt beim Zurueckkommen mit dem eigenen since nach.
Ein Hintergrund-Tab braucht keinen Live-Feed; das spart nebenbei
Server-Worker und Akku. Ein SharedWorker waere sauberer, ist aber eine eigene
Baustelle fuer ein Problem, das die einfache Loesung praktisch beseitigt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
mhoennig
2026-08-26 15:30:03 +02:00
co-authored by Claude Opus 5
parent b6509ae537
commit af8a7b74b3
2 changed files with 20 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
backend/docs/client-live-editing-instructions.md
+11 -1
View File
@@ -224,7 +224,17 @@ hält den Ablauf, `app.js` nur die Verdrahtung.
der Schutz. der Schutz.
Nur **eine** Feed-Anfrage gleichzeitig; `AbortController` benutzen und beim Nur **eine** Feed-Anfrage gleichzeitig; `AbortController` benutzen und beim
Dokumentwechsel/Unmount abbrechen. `status = 'offline'` gilt, sobald ein Dokumentwechsel/Unmount abbrechen.
**Der Feed läuft nur im sichtbaren Tab.** Bei `visibilitychange` auf verborgen
die Verbindung schließen, beim Zurückkommen einmal mit dem eigenen `since`
nachholen und weiterpollen. Grund: Der Zielserver bietet **kein HTTP/2**
(gemessen), also gilt das Browser-Limit von sechs Verbindungen je Herkunft —
ein dauerhaft offener Long-Poll je Tab engt bei mehreren Tabs alles andere
ein. Ein Tab im Hintergrund braucht ohnehin keinen Live-Feed: Niemand schaut
hin, und beim Sichtbarwerden holt ein einziger Request den ganzen Rückstand.
Spart nebenbei Server-Worker und Akku. Der Editor hört für die Höhenmessung
schon auf `visibilitychange` (D17-Nachtrag 4) — die Stelle gibt es also. `status = 'offline'` gilt, sobald ein
Request am Netz scheitert, und endet mit der nächsten erfolgreichen Antwort; Request am Netz scheitert, und endet mit der nächsten erfolgreichen Antwort;
lokale Änderungen bleiben dabei erhalten und werden danach normal geflusht. lokale Änderungen bleiben dabei erhalten und werden danach normal geflusht.
docs/DECISIONS.md
+9 -2
View File
@@ -5927,8 +5927,15 @@ Antwort am Ende des Wartens.
Drei Befunde bleiben als Arbeit stehen. **Kein HTTP/2** — damit gilt das Drei Befunde bleiben als Arbeit stehen. **Kein HTTP/2** — damit gilt das
Browser-Limit von sechs Verbindungen je Herkunft, und mehrere Tabs derselben Browser-Limit von sechs Verbindungen je Herkunft, und mehrere Tabs derselben
Person binden je eine dauerhaft; zu beheben serverseitig oder clientseitig Person binden je eine dauerhaft. **Entschieden: Der Feed läuft nur im
über einen SharedWorker, der allen Tabs eine gemeinsame Feed-Verbindung gibt. sichtbaren Tab** — bei `visibilitychange` schließen, beim Zurückkommen einmal
mit dem eigenen `since` nachholen. Ein Hintergrund-Tab braucht keinen
Live-Feed, niemand schaut hin, und ein einziger Request holt den Rückstand;
das spart nebenbei Server-Worker und Akku. Erwogen und verworfen war ein
**SharedWorker**, der allen Tabs eine gemeinsame Verbindung gibt — technisch
sauberer und auch für Hintergrund-Tabs aktuell, aber eine eigene Baustelle
mit Nachrichtenprotokoll, Lebenszyklus und Rückfallpfad, für ein Problem, das
die einfache Lösung praktisch ganz beseitigt.
**Nur Java 17** installiert, während `build.gradle.kts` **Nur Java 17** installiert, während `build.gradle.kts`
`JavaLanguageVersion.of(21)` verlangt. Und der **Weg vom Apache zum Backend `JavaLanguageVersion.of(21)` verlangt. Und der **Weg vom Apache zum Backend
ist ungeklärt**: `ProxyPass` ist in `.htaccess` nicht zulässig, ist ungeklärt**: `ProxyPass` ist in `.htaccess` nicht zulässig,