Ein grundsätzliches Problem mit GTchat 0.95 war es, dass dort zu
viel und an falschen Stellen optimiert wurde. Deswegen wurde in
GTchat 0.96 der Kern aufgeräumt, alles in allem wurden richtige
Änderungen gemacht. Dieser Teil der Änderungen ist auch bereits
abgeschlossen, mit Ausnahme einer Kleinigkeit: eine Optimierung in
sendOutputStrings hatte ich noch geplant. Anstatt die Zeichenfolgen
sofort zu verschicken, sondern die Funktion diese sammeln, damit sie
beim Beenden der Verarbeitung alle zusammen verschickt werden.

Gleichzeitig habe ich allerdings Änderungen in den Schablonen
vorgenommen. Diese wurden nicht abgeschlossen, so wurden die
Schablonen fürs Admin-Interface, Privatnachrichten und Moderation
nicht verändert. Hauptsächlich waren diese Änderungen eine
Fehlentwicklung:

* XHTML'isierung der Schablonen: ist dem Otto-Normal-Webmaster nicht
zuzumuten. Obwohl ich XHTML selber immer noch gerne benutze, sehe
ich die Benutzung von XHTML durch unerfahrene Webmaster eher
kritisch. Die Regeln von XHTML sind sehr strikt und erfordern ein
gutes Verständnis von XML. Ist das nicht gegeben, kommen Fehler
rein, die ein Browser ohne XHTML-Unterstützung wie Internet Explorer
(und manchmal sogar der Validator) nicht anzeigt. Anschliessend
wundert sich der Webmaster, warum Leute mit Firefox nicht in den
Chat kommen können. Diese Änderung muss auf jeden Fall rückgängig
gemacht werden.
* Aufräumung und Modernisierung des HTML-Codes: ist positiv zu
bewerten und war überfällig. In GTchat 0.95 wurden Abstände immer
noch am liebsten mit leeren Tabellenzeilen und   eingesetzt -
der Gebrauch von CSS war rudimentär. Die Aufräumung ging höchstens
nicht weit genug.
* Die Funktionen des Chats in einer grafischen Symbolleiste: einfach
nur häßlich. Auch habe ich mittlerweile verstanden, dass man nicht
versuchen sollte, Bedienelemente von lokalen Anwendungen zu
kopieren. Die beste Lösung wäre hier wohl ein dynamisches Menü
(Smileys wären dann einfach ein Untermenü statt Popup) oben auf der
Seite. Dazu müsste man aber die Frames loswerden, siehe unten.
* Zusammenklappen von Teilbereichen des Chat-Fensters: die Idee war,
dass Leute, die nur schreiben, Platz sparen und einen größeren
Textbereich haben könnten. Da wäre es wohl besser gewesen, einfach
von vornherein nicht zu viel Platz zu verschwenden.

Viel besser wäre es, wenn das Chat-Fenster ganz auf Frames
verzichten würde. Eigentlich braucht man ja nur zwei iframes auf der
Seite: eines, um Daten zum Server zu schicken, und eines, das eine
permanente Verbindung zum Server aufrechterhält (nur im
Server-Push-Modus). Der Server würde HTML als JavaScript-Anweisungen
schicken, was er im Client-Pull-Modus ja bereits tut. Dieser könnte
anschliessend via DOM in das DIV übertragen werden, das den
Chat-Text enthält. Eventuell könnte man den HTML-Code sogar im
Browser aus client-seitigen Schablonen generieren. Auch
Aktualisierungen für die Raum- und Benutzerliste kommen als
JavaScript-Anwesungen, die Listen werden via DOM manipuliert.

Vorteile: wenn sich der Chat öffnet, wird nur eine Seite geladen,
anstatt vier wie jetzt. Es werden nicht ständig Frames neu geladen,
eine permanente Verbindung zum Server reicht für alle
Aktualisierungen. Das Layout des Chat-Fensters kann komplett per CSS
festgelegt werden (iframes haben da durchaus schon Probleme
bereitet). Das Scrollen beim Erhalt einer neuen Nachricht wird
trivial - bisher wußte man ja nicht, wann eine Nachricht kommt. Im
Log-Fenster kann eine Kopie dessen anzeigen, was man erhalten hat,
anstatt per innerHTML den Textbereich zu kopieren - diese Kopie
unterscheidet sich zu oft vom Original. Usw...

Weiterhin sollte es möglich sein, auf Popups zu verzichten (von
einem modernen Benutzerinterface würde man so etwas erwarten). Man
könnte Tabs unter dem Textbereich anbringen - ein Tab für den Raum,
in dem man sich gerade befindet, und je eines für jede Unterhaltung
via Privatnachrichten. Das Umschalten der Tabs würde einfach ein DIV
unsichtbar und das andere sichtbar machen - keine Schwierigkeiten
hier. Wenn im nicht-aktiven Tab neue Nachrichten eintreffen, ändert
man z.B. die Textfarbe auf der Tab-Überschrift oder lässt diese
blinken - endlich eine Lösung für das Problem, dass
Privatnachrichten in einem Fenster eintreffen, das man gerade nicht
sieht. Man könnte es auch so machen, dass man in mehreren Räumen
gleichzeitig anwesend sein darf - falls Text sowieso per
JavaScript-Befehle hereinkommt, kann man es problemlos auf mehrere
Tabs verteilen.

Admin-Interface sollte man eine echte AJAX-Anwendung machen. Wenn
man mutig ist, kann man die Kommunikation mit dem Server sogar über
XMLHttpRequest gestalten, bei den Chat-Admins kann man ja etwas
höhere Forderungen an den Browser stellen. HTML-Code sollte über DOM
manipuliert werden.

Die Entscheidung, ob man Server-Push oder Client-Pull verwendet,
sollte nicht dem Benutzer überlassen werden. Es ist einfach genug,
diese Entscheidung *nach* dem Chat-Eintritt zu fällen (proxycheck
ist eine schlechte Lösung). Es wird erstmals angenommen, dass
Server-Push unterstützt wird. Der Server schickt ein
JavaScript-Befehl, woraufhin der Client mit einem bestimmten
Chat-Befehl antworten muss. Wird dieser Befehl innerhalb einer Zeit
(10 Sekunden?) nicht empfangen, kann angenommen werden, dass die
Zustellung der Daten über die permanente Verbindung nicht
funktioniert und man Client-Pull verwenden muss, die permanente
Verbindung wird serverseitig geschlossen.

• Sehr umfassende Einstellungsmöglichkeiten
  
• Fast alle Einstellungen können über die Admin-Funktionen des Chats angepaßt werden
  
• Minimale Verzögerungen dank Server-Push-Technik
  
• Kleiner Ressourcenverbrauch
  
• Keine Datenbank notwendig
  
• Eingebaute Traffic-Statistik
  
• Smileys können verwendet werden (falls erwünscht)
  
• Verschiedene Benutzergruppen: Gast, User, Superuser, Administrator, Chat-Master
  
• Einfache Erstellung/Änderung von Räumen, Nicht-Administratoren können temporäre Räume erstellen
  
• Geschlossene Räume, User können eingeladen werden
  
• Moderierte Räume, VIPs
  
• Privatnachrichten können nur vom Adressaten gelesen werden (auch nicht von Admins)
  
• Administratorfunktionen: zeitweises Redeverbot, Rausschmiß, Sperre des Accounts oder der Adresse
  
• Logging für die öffentlichen Texte
  
• Komplette Übersetzung ohne Änderungen des Programms möglich
  
• Mitgelieferte Templates funktionieren sowohl mit Internet Explorer als auch Netscape Communicator (jeweils ab Version 4.0)
  
• Einfache Änderung der Farben in der CSS-Datei, keine Änderungen der Templates notwendig
  
• usw...