...tbd:

• => Das Aufbauen der Darstellung soll die Nutzer nicht verwirren, sondern konsistent und nachvollziehbar sein. Keine Flash-Effekte oder Geflatter etc. .
• => Die App soll in kürzester Zeit (unter 3 Sekunden ?) für Aktionen der Nutzer aufnahmebereit sein.
• => Das WIM-System soll auch möglichst weitgehend offline nutzbar sein (aus dem lokalen Speicher bzw. Browser-Cache ?)
• => Möglichst alle öffentlichen(!) Informationen eines Projektes müssen auch durch (dafür freigegebene) Suchmaschinen-Roboter abrufbar sein.
• => Auch mit Browsern, die nicht dem Stand der Technik entsprechen oder bei denen Scripting ausgeschaltet ist, müssen möglichst alle öffentlich zugreifbaren Informationen abrufbar sein - wenngleich auch nicht immer mit allem "Komfort".
• => Beim Aufruf von Infos aus Ergebnislisten der Suchmaschinen heraus sollte immer die WIM-App starten, wenn es die Browser-Konfiguration zulässt.
• => Der Abruf der öffentlichen(!) Infos sollen auch per RSS2- oder atom-Feed möglich sein.
• => Unerwünschte Aufrufer sollen geblockt werden können.
• => Unmäßig intensive Nutzungen sollten automatisch gebremst werden können. (Ungewollte) "Endlos-Aufrufschleifen" im System dürfen das System nicht blockieren.
• => Bei den verwendeten Kommunikationsadressen ist eine Unabhängigkeit von der verwendeten Software sicherzustellen. Für Nutzer der Frontend-Server sollte möglichst nicht bemerkbar sein, welche Software auf dem Server gerade verwendet wird.

...

...

...

Die Frontend-Server stellen die direkte Schnittstelle zwischen den Internet-Browsern der Nutzer und den im Internet gespeicherten Daten und Programmen dar. Für die primäre Speicherung der Objekt-Daten sind die Backend-Server zuständig. Die Frontend-Server haben die Aufgabe, die konkret nachgefragten Daten möglichst schnell zu liefern und die Backend-Server von allen direkten Anfragen aus den Weiten des Internets abzuschirmen.

Die Aufgabenbereiche im Einzelnen:

"Spontan" eintreffende Anfragen:

§ Siehe auch Wie werden Aufrufe der Basis-URL vom Frontend-Server bearbeitet?

• => Alle Aufrufe der Internetseiten einer Internetpräsenz oder zum Starten einer WIM-App müssen bearbeitet und beantwortet werden.
• => Auch alle Aufrufe von Internetbrowsern, bei denen das WIM-Laufzeitsystem nicht gestartet werden kann (beispielsweise mangels Browser-Fähigkeiten) oder soll (weil Scripting abgeschaltet /blockiert wurde), müssen angenommen und bearbeitet werdenli>
• => Anfragen von "erwünschten" Suchmaschinen-Robotern werden so beantwortet, dass die gelieferten Daten von ihnen gut verarbeitbar sind. Anfragen unerwünschter Suchmaschinen-Roboter werden wie "Hacking"-Anfragen behandelt.Die Identität der erwünschten Suchmaschinen-Roboter wird verifiziert.
• => "unerwünschte" (Hacking-) Anfragen werden nach Möglichkeit blockiert. Beispielsweise, in dem die Antworten sehr stark verzögert werden und ein abweisender http-Statuscode zurückgesendet wird.
• => Anfragen zu nicht existierenden Dateien werden meist wie Hacking-Anfragen behandelt. Wenn eine Analyse ergibt, dass es sich sehr wahrscheinlich um eine Hacking-Anfrage handelt, können "verschärfte Maßnahmen" (IP-Blockade, ...) aktiviert werden. IP-Blockaden sollten an alle openWIM-Server weitergemeldet werden.
• Bei neu aufzunehmenden Sitzungen auf einem überlasteten Server oder Nichtverfügbarkeit des angesprochenen Servers (Wartung etc.) kann eine automatische Weiterleitung auf einen verfügbaren bzw. weniger ausgelasteten Server erfolgen.

Laufende Sitzung, Datenaustausch:

• => Anfragen von Clients oder anderen openWIM-Servern nach Objekt-Daten werden beantwortet. Eventuell benötigte Berechtigungen werden überprüft.
• => Empfangene Daten werden verarbeitet und ggf. weitergegeben, wenn die Berechtigung der Sender vorliegt.
• => Wenn Daten von einem Client (oder anderen Frontend-Server) abonniert wurden, werden betroffene aktualisierte Daten an die Abonnenten weitergemeldet.
• => Wenn die Kommunikation mit einem Client zu lange unterbrochen wird (beispielsweise, wenn ein Client-Gerät vorübergehend abgeschaltet wird oder wenn die Netzwerk-Verbindung wegen Durchqueren eines Mobilfunk-Lochs etc. unterbrochen wurde), wird die im Prinzip "endlose" Sitzung pausiert.
• => Wiederaufnahme einer Sitzung: Meldet sich ein Client nach einer Sitzung-Pause wieder, kann die Sitzung wieder aufgenommen werden, wenn die Autentifizierung gelingt. bei nur kurzen Pausen werden aufgestaute Daten gesendet, ansonsten müssen sich Client und Friontend-Server synchronisieren und beispielsweise zwischenzeitlich aktualisierte Daten austauschen.

Bereitstellung von Dateien:

• => Dateien werden (zur Ausfallsicherheit) in Kopie unter allen URLs eines Projektes gehalten und an die Aufrufer herausgegeben - falls sie keinen Zugriffs-Restriktionen unterliegen.
• => Nichtöffentliche Dateien ( files/private/ oder files/projectname/private/ ) dürfen nur an berechtigte Aufrufer herausgegeben werden. Die Verzeichnisse sind gegen direkte Aufrufe geschützt.
• => Eventuell für ein Projekt unter einer seiner URLs noch nicht bereitgestellte Dateien (Grafiken, PDF-Dateien, ...) müssen von geeigneter Stelle (beispielsweise dem Backend-Server der zuständigen Projektgruppe) besorgt und an die Aufrufer weitergegeben werden. Pro Projekt wird eine Adressliste möglicher Datei-Quellen gehalten.

Spezielle Kommunikation, RPC:

• => Nutzeranmeldungen werden (mit Rückgriff auf den Backend-Server) durchgeführt,
• => Administrative Aktionen können vom Client veranlasst werden, wenn die notwendige Berechtigung vorliegt.
• => Sofern auf einem Frontend-Server Kopien aller Daten vorliegen, können die Frontend-Server möglichst viele Leistungen für die Clients erbringen. Sie arbeiten notfalls weitestgehend ohne Backend-Server.

Bereitstellen, aktualisieren unf ausliefern von generierten Dokumenten /Fragmenten:

• => Bei allen "spontanen" Anfragenvon Clients an den Frontend-Server wird eine einfache Seite im "uncomplicated"-Format mit der Darstellung des abgerufenen Objektes bzw. der Startseite mitgeliefert. Diese einzubettenden Darstellungen sollen als Dokument-Fragmente zum einfachen Einbetten bereitstehen. Der Frontend-Server muss dafür sorgen, dass diese Fragmente bei Bedarf erstellt und aktualisiert werden. Nötigenfalls mit Hilfe eines Support-Servers.
• => Bei Internetpräsenzen können RSS- und/oder Atom-Feeds bereitgestellt werden. Der Frontend-Server muss diese Dokumente bei Bedarf erzeugen, aktualisieren unf ausliefern. Nötigenfalls mit Hilfe eines Support-Servers.
• ...

.

Für das WIM-System ist die schnell erreichte "Sichtbarkeit" und Arbeitsfähigkeit der App nach ihrem Aufruf im Browser von essentieller Bedeutung, weil sie die Nutzer animiert, "schnell mal" die App aufzurufen - auch wenn sie (in der Regel) erst vom Server geladen werden muss. Der Frontend-Server muss aber auch auf andere Anfragen reagieren, sodass die Optimierung nicht beliebig einseitig erfolgen darf.

Folgende Ziele und Randbedingungen sind dabei zu berücksichtigen:

• => Der Aufruf der Projektseite (bzw. der App) durch die Nutzer soll in kürzester Zeit (deutlich unter 1 Sekunde) eine gut erkennbare, vernünftige Reaktion zeigen können.
• => Das Script im Frontend-Server muss für den Regelfall möglichst kurz (und damit spezialisiert) gehalten werden.
• => Falls eine vom Normalfall abweichende Reaktion nötig wird, können weitere Script-Module nachgeladen werden. Das geht auch ohne mod_Perl etc. .
• => Das Script darf nicht prokektspezifisch sein, damit das Aufsetzen oder Ändern des Scripts automatisiert erfolgen kann.
• => Das Script darf eine Datei einlesen, die projektspezifische Daten sowie alle Basis-Style-Definitionen und Basis-Scripts enthält. Diese Daten werden mit einem Rahmen versehen an den Browser zurückgeschickt.
• => Die an den Browser zu sendenden einzubindenden Dateien müssen vom Server stets automatisch auf dem aktuellen Stand gehalten werden.
• => Initial zu ladende Grafiken (beispielsweise Logos) sollten möglichst im SVG-Format bereitgestellt und direkt in die einzubindende Datei eingefügt werden, damit keine separate Nachlade-Aktion erfolgen muss.
• => Das Frontend-Server-Script prüft, ob ein Aufruf von einem erwünschten Submaschinen-Roboter kommt und überprüft ggf. seine Identität. Der Bot bekommt eine vorbereitete Datei geliefert, die alle Daten für die Darstellung des aufgerufenen Objektes enthält (könnte aus dem Suchmaschinen-Cache heraus aufgerufen werden)
• => Die Suchmaschinen-Bots werden nach Möglichkeit auf die Feed-Varianten der Objektdarstellungen geleitet.
• => Das Frontend-Server-Script prüft einige Query-Parameter und sendet beispielsweise für Debug-Zwecke alternative Daten wie die Anforderung zur Verwendung unkomprimierte Sccripts.
• => Falls ein?show=ObjSpec -Parameter entdeckt wird, wird die Suchmaschinen-Bot-Variante des aufgerufenen Objektes gesendet. Ist im Browser das WIM-Laufzeitsystem nutzbar, wird es nachgeladen und gestartet.
• => Aufrufe der Basis-Url mit Angabe von Dateinamen führen in aller Regel zu 404-Fehlern etc., die dann entsprechend (von einem anderen Script) bearbeitet werden.
• .

• ...

• Für ein schnelles Hochfahren der App im Browser ist folgendes wichtig:
  • Die Hash-Tags der im Browser angegebenen Url müssen ausschließlich im Browser bearbeitet werden. Sie werden NICHT zum Server übertragen.
  • Ist ein "show" Query-Parameter angegeben oder ist erkennbar, dass der Aufruf von einem Suchmaschinen-Roboter oder einem "dummen" Browser kommt, müssen Module zur speziellen Bearbeitung nachgeladen werden.
  • Bei Servern ohne eigene Datenbanken kann die Abfrage an einen "versteckten" sekundären Frontend-Server zur Bearbeitung weitergereicht und dessen Antwort zurückgemeldet werden.
• Für eine schnelle Reaktion auf Nutzeraktionen ist im Server-Kontext folgendes wichtig:
  • .
• => Die verschiedenartigen Abfragen
  • WIM-Boot und Suchmaschinen-Aufrufe,
  • Objektparameter-Abfragen,
  • Meldung von verfügbar gewordenen Daten oder anderen Requests vom Server an die App,
  • Abfrage nichtöffentlicher Objektparameter,
  • Abfrage dynamischer Projekt-Parameter bzw. RPC-Aufrufe wie Login etc.,
  • Feed-Aufrufe,
  • ...
  sollten über verschiedene - meist möglichst kleine - URLs und spezialisierte Scripte erfolgen, damit unnötiger Overhead vermieden wird.
• tbd.
• .

...

• Damit für die "uncomplicated" Nutzung möglichst wenige Daten bei Folgeaufrufen stets erneut übertragen werden müssen, werden die allgemeinen Style-Definitionen dafür in einer separat zu ladenden (Datei zusammengefasst.
• Ebenso wird Script-Code, der die Fähigkeit zur Ausführung des WIM-Laufzeitsystems beim Nutzer-Agenten (=Browser) testet, in separat zu ladenden JavaScript-Dateien zusammengefasst.
• Sofern möglich, wird bei der Boot-Seite ein als SVG-Grafik erstelltes Logo direkt in das HTML eingebettet und langsam eingeblendet. Das geht schneller, wie das Einbinden einer Image-Datei. SVG-Grafiken sind darüber hinaus auch meist kleiner wie Bitmap-Grafiken sowie beliebig skalierbar, ohne Unschärfe oder Rastereffekte zu zeigen. Bei Inkscape gibt es eine "Entrümpelungs"-Funktion zum Ausmisten von unnötigem Inhalt, was die Dateigröße erheblich reduzieren kann (bei ZRM-Logo fast 50%).
• Beim Aufruf der "Boot"-Datei wird erstmal nur nur ein Mini-(Perl- oder PHP-) Script gestartet.
  > Falls der Aufruf zur Anzeige eines dedizierten Objektes erfolgt ( ?show=Xxx ) oder von einem registrierten Suchmaschinenroboter erfolgt, wird ein erweitertes Script geladen (bzw. ein Service-Prozess für komplexeres Handling angesprochen).
• Sollte das Boot-Script bereits alle normalerweise zu übertragenden Inhalte enthalten oder sollten diese aus einer Datei ausgelesen werden? Was geht signifikant fixer ?
• Die Boot-Datei sollte mit einem weit gefassten Ablaufdatum zum Browser gesendet werden, damit sie in der Regel aus dem Cache geholt werde. Beim Hochfahren sollte dann überprüft werden ob eine neuere Version bereitsteht und die Boot-Datei explizit neu geladen werden bzw. die veralteten Werte werden überschrieben. Bei offline-Aufrufen kann mit der Cache-Version gearbeitet werden.
• tbd
• Mit der ersten (HTML-)Datei müssen möglichst bereits alle Daten für die standardmäßig vorgenommenen projektspezifischen Verarbeitungen bereitgestellt werden. Für spezielle (seltene) Aktionen können Daten nachgeladen werden.
• Da im Prinzip unklar ist, welcher "Nutzer-Agent" die URL aufgerufen hat, kann beim WIM-System nicht einfach eine fixe HTML-Datei übergeben werden, sondern die URL muss das anzuzeigende Objekt enthalten und die HTML-Datei muss den HTML-Code für die "einfache" Darstellung des aufgerufenen Objektes liefern. Dieses ist besonders für Aufrufe von Suchmaschinen-Roboter relevant.
• .

...

• ...