Grundsätze der Client-Architektur

Diese Seite beschreibt wie ein Client strukturiert sein sollte, nicht das Format der ausgetauschten Nachrichten (siehe Datenmodell und die folgenden Seiten dafür).

Grundsatz: ein einziger Datastore hält die Wahrheit

Der Client verwaltet eine einzige Datenstruktur, die den aktuellen Zustand abbildet (Module → Properties → Elemente). Die gesamte UI liest diese Struktur; nichts anderes verändert sie außer den vom Server empfangenen Nachrichten.

Lesen    :  Datastore ────────────► UI

Schreiben:  UI ─── SV/SA ───► Server ─── Update ───► Datastore

• Keine Duplizierung: Braucht eine Komponente einen Wert, liest sie ihn aus dem Datastore, statt eine eigene Kopie zu halten.
• Kein direktes Schreiben: Die UI verändert den Datastore niemals selbst, auch nicht für eine optimistische Anzeige.

Grundsatz: keine Internet-Abhängigkeit

Ein OST-Server läuft häufig in einem isolierten lokalen Netzwerk — ein entlegener Observatoriumsstandort ohne Weg zum öffentlichen Internet ist ein normales Einsatzszenario, kein Randfall. Ein Client muss dort korrekt funktionieren: jede benötigte Ressource muss mit dem Client selbst ausgeliefert werden, nicht zur Laufzeit von einem CDN oder einem anderen externen Dienst geladen werden.

Das betrifft direkt das Rendering der Icons: preicon1/preicon2/posticon1/posticon2/preicon/posticon liefern einen Google-Fonts-Icon-Namen (Material Icons), keine URL — ein Client muss die Icon-Schrift/Glyphen lokal mitliefern (vendored, selbst gehostet oder beim Build gebündelt), statt das CDN-Stylesheet von Google zu laden, das in dem Moment stillschweigend versagt, in dem keine Route ins öffentliche Internet mehr besteht.

Dasselbe gilt für alles andere, was ein Client versucht sein könnte, von einem CDN zu laden: ein JS-Framework, eine Diagramm-Bibliothek, eine Web-Schriftart für die UI selbst. Wenn der Client es zum Laufen braucht, wird es mit ausgeliefert.

Starke Empfehlung: mindestens ein dunkles und ein helles Theme unterstützen

OST-Clients werden häufig am Okular oder neben einem Teleskop genutzt, nachts — eine UI mit voller Helligkeit und weißem Hintergrund ist dort nicht nur ein stilistischer Missgriff, sie ruiniert aktiv die Nachtsicht des Anwenders. Ein Client sollte mindestens sowohl ein dunkles als auch ein helles Theme anbieten, statt eines der beiden fest zu verdrahten.

Das ist nicht Teil des Wire-Protokolls — nichts davon wird serverseitig erzwungen oder ist dort überhaupt sichtbar —, aber es ist eine starke Empfehlung für alles, was für echte Astrofotografie-Sessions gedacht ist, nicht nur als Demo oder Schreibtisch-Testwerkzeug.

Vollständiger Dump vs. teilweise Updates

Bei der Verbindung sendet der Client DU; der Server antwortet mit einem vollständigen Dump (d), der alle Module mit ihren vollständigen Metadaten enthält (Label, Typ, Min/Max, LOV usw.).

Rendering: Aktualisierungen auf die geänderte Property beschränken

Templates: Bildschirme pro Modultyp mit generischem Fallback

Jede Modulinstanz kann infos.template angeben (siehe Datenmodell) — eine Zeichenkette, die ihren Typ benennt ("focus", "guider", "sequencer" …). Das ist nur ein Hinweis, und er darf fehlen.

template = infos.template?.toLowerCase() || "default"
screen = registry[template] ?? registry["default"]

Property-Formulare: SA, verpflichtend bei directedit: false

Über das feldweise SV hinaus braucht eine editierbare Property einen Formular-Pfad: einen Bildschirm, der alle ihre editierbaren Elemente auf einmal auflistet und zusammen über SA sendet.

Nur editierbare Elemente gehören in dieses Formular — reine Anzeige-Typen (img, video, light, prg, message) werden gerendert, nie gesendet; sie sollten ganz aus dem Payload weggelassen werden, statt ihnen einen bedeutungslosen Wert zu geben.

Dieselbe „mehrere Elemente auf einmal senden"-Form wird auch von der Grid-Zeilen-Erstellung (GC) und -Aktualisierung (GU) verwendet — beide nehmen eine e-Map genau wie SA. Es lohnt sich, eine wiederverwendbare Formular-Komponente zu bauen, die sowohl das reine Property-Formular als auch den Grid-Zeile-erstellen- und den Grid-Zeile-bearbeiten-Dialog bedient, statt drei getrennte Implementierungen derselben Logik („editierbare Elemente rendern, ihre Werte sammeln"). Rooster macht das so.

Heartbeat

→ {"XX": {}}
← {"xx": {}}

Wiederverbindung

Minimales Beispiel: erster Austausch

Ohne Framework, nur der allererste Austausch (verbinden → DU → zuhören) — entnommen aus test-ws-advanced.js, dem Skript für den stündlichen Health-Check des Servers:

const ws = new WebSocket("ws://127.0.0.1:9624");

ws.on("open", () => {
  ws.send(JSON.stringify({ "DU": { "language": "en" } }));
});

ws.on("message", (data) => {
  console.log("received:", data.toString());
});

Beispiel: Lesen und Schreiben in Rooster

Reale Ausschnitte, die die eingangs beschriebene Trennung von Lesen und Schreiben veranschaulichen, sobald ein tatsächlicher Client (hier Rooster, in Angular) nach diesem Grundsatz aufgebaut ist.

Lesen — datastore.service.ts, ein einfacher Zugriff auf den internen Zustand:

getProperty(moduleName: string, propertyName: string): Observable<any> {
  return new Observable(subscriber => {
    const subscription = this.changed$.subscribe(() => {
      const module = this.modules[moduleName];
      const prop = (module as any)?.properties?.[propertyName] || null;
      subscriber.next(prop);
    });
    subscriber.next(this.modules[moduleName]?.properties?.[propertyName] || null);
    return () => subscription.unsubscribe();
  });
}

Schreiben — websocket.service.ts, keine lokale Mutation, nur das Senden der Nachricht:

setPropertyOneElement(module: string, property: string, elements: { [key: string]: any }): void {
  this.send({
    SV: { m: { [module]: { p: { [property]: { e: elements } } } } }
  });
}