Zum Thema Browserchat interessiert mich, wie das eigentlich statische HTTP/WWW so umgeformt wird, dass dynamisch DAS nachgeladen wird, was andere gerade sagen. NOrmalerweise verändert sich ja eine WEbsite nicht mehr, nachdem sie geladen wurde... chats hingegen laufen einfach weiter, ohne, dass man die seite neu laden muss
Danke, --Abdull 09:33, 1. Apr 2005 (CEST)
- es wird nur der Frame (HTML) des Chatfensters neu geladen und zwar funktioniert das meist über spezielle Scripte (siehe Programmiersprache Perl/CGI) oder aber eben über eingebettete Java-Applets. --84.161.213.141 22:10, 8. Sep. 2007 (CEST)
- das stimmt so nicht, es gibt auch anbieter deren chats nicht per pull (reload) sondern per server-push funktionieren und trotzdem über http und ohne plugins/java etc. laufen, z.b. webkicks.de. soweit ich weiß wird dort die http-verbindung offen gehalten und irgendwie dafür gesorgt, dass über die offene http verbindung dann immer wieder neue zeilen nachgeschickt werden. ist dann nur dumm, wenn das lokale virenprogramm sich einklinkt und die datei zum scannen erst cachen will - dann sieht man nichts weil das virenprogramm ewig darauf wartet, dass die datei endlich abgerufen wurde und sie so lange nicht an den browser weitergibt. --87.152.90.163 23:42, 9. Jan. 2008 (CET)
- das prinzip des server-push ist mir bekannt. Der nachteil ist halt je nach webserver und/oder script- bzw. programmiersprache teilweise schlecht (oder nur mit tricks) realisierbar ist, weiterhin gibt es merkwürdige verhaltensweisen mit manchen proxies. Der vorteil ist dass die inhalte sofort dargestellt werden und es für beide seiten ressourcenschonender als chats mit poll-technik ist. Weiterhin kann damit je nach zugrundeliegender servertechnik auch ein sofortiger logout ohne aktivem zutun des users beim schließen oder beim wechsel der seite realisiert werden. Diese art von chats verwendet bei clientseite übrigens üblicherweise javascript, damit der user nicht per hand nachscrollen und nicht ständig bei der eingabe einen ok-button drücken oder in die eingabzeile klicken muss. Ich finde es sollte in diesem thema auch erwähnt werden. --WarPigs (Diskussion) 21:17, 11. Feb. 2013 (CET)
Java-Chat
Bearbeiten("Stream-over-HTML" = Original Research, technisch falsch denn bereits Apache und NPH-CGI konnten Streaming in den 90ern, Javachats werden bereits im letzten Abschnitt erwähnt)
Java-Chats werden als Applet basierte Chats aufgeführt. In meinem Beitrag habe ich jedoch Java-Webserver Chats genannt. Der unterschied liegt darin, dass die Server Architektur auf java basiert und darüber die Chat Engine zur verfügung gestellt wird. Java Applets hingegen werden lokal auf dem Client ausgeführt. Im klartext: In einem Fall wird die Serverlaufzeitumgebung durch java bereitgestellt, im andern fall (Java Applet) wird die Clientsoftware durch lokale ausführung auf dem Clientrechner zur verfüngung gestellt. Ein Java Serverbasierter Chat kann mit einem Webbrowser also auch benutzt werden, wenn gar kein Java auf dem Client installiert ist. Etwas ähnliches meint der Beitragsautor über mir auch mit der Push und Pull funktion. Ich bitte daher um korrektur des Löschens meines Beitrags. --2ndjpeg 18:31, 26. Jul. 2009 (CEST)
- Bei deinem Beitrag gab es keine Informationen zur Geschichte und Technologie von Webchats, das war Original Research und Werbung für ein "Silverorbit Chat V3 Server Edition". Den Begriff Stream-over-HTML gibt es nicht (5 Googlehits [1]), die technische Einordnung von Streaming ist komplett falsch (gibt es seit den in den 90ern [2]), dass ein Chatserver-Backend in Java geschrieben sagt nichts über die verwendete Webtechnologie aus, der gelinkte Artikel Medieninformatik kennt keine Begriffe "Reload-Chat und "Stream-Chat". -- 83.254.210.47 00:55, 27. Jul. 2009 (CEST)
- Der Beitrag ist sowieso inkorrekt, da man keine spezielle Serversoftware braucht. Jeder Webserver mit Unterstützung von Scriptsprachen ist dazu grundsätzlich in der Lage (z.B. apache+mod_php/mod_mono, Tomcat, etc.). Die technische Einordnung in den Bereich Streaming ist meiner Meinung nach jedoch korrekt, solange der Chat nicht auf einem Reload-Prinzip beruht (per HTTP-Header oder meta http-eqiv refresh). Zitat "Mit Datenströmen (englisch: data streams) bezeichnet man in der Informatik kontinuierliche Abfolgen von Datensätzen, deren Ende nicht im Voraus abzusehen ist." Auch wenn die Begriffe "Reload-Chat" und "Stream-Chat" sicher nicht allzu häufig anzutreffen oder im Duden zu finden sind, weiß jeder, der sich mit der Programmierung eines Chats beschäftigt hat, was gemeint ist: Einer der 2 grundsätzlichen Ansätze in diversen Chat-Systemen entweder per Nachladen einer Seite, die dann die aktuellsten Chat-Zeilen nachlädt oder per endlosem (HTML-)Stream, dem kontinuierlich die Chat-Zeilen hinzugefügt werden bzw. bei Inaktivität HTML-Kommentare oder Leerzeichen, um ein Timeout zu verhindern. Zusätzlich gibt es noch eine Mischform, in der per kontinuierlichem Reload in einem unsichtbaren Frame JavaScript vom Server geladen wird, welches dann die Zeilen einem anderen Frame hinzufügt, um es so aussehen zu lassen, als würde der Chat einfach fortlaufen. --193.159.112.36 23:41, 6. Jun. 2011 (CEST)
Fehlerhafte Details im Beitrag
Bearbeiten"Das Versenden von Nachricht an den Chatserver erforderte ein komplettes Neuladen der Webseite." Das ist inkorrekt, siehe andere Diskussion -> Streaming "Das Empfangen von neuen Nachrichten bedeutete außerdem dass Webseiten regelmäßig neu geladen werden mussten." Ist ebenfalls inkorrekt
Leider sind die meisten der mir bekannten Webchats, die beide Punkte als Live-Beispiel widerlegen könnten, mittlerweile geschlossen: -nidura.de: Geschlossen wegen zu wenig Nutzern. -kilahu.de: Nach einem Hardware-Ausfall wurde der Chat-Bereich nie wieder reaktiviert. -netanic.de: Scheint es noch zu geben.
"Dies konnte zu Verzögerungen führen, zu Flackern beim Seitenaufbau und ständigen, störenden Browseraktivitäten." Diese Folgerung ist nicht generell korrekt und betraf/betrifft nur einige der Webchats.
"Aus diesen Gründen sind reine HTML-Webchats weitgehend zurückgegangen." Ist eine unbelegte Meinung, meiner ebenfalls unbelegten Meinung nach sind HTML-Webchats durch das Erscheinen von sozialen Netzwerken (facebook, etc.), neuen Browserversionen, die zu den bekannten Problemen von HTML-Webchats weitere mitbrachten, sowie Firewall-Lösungen und Proxies, die den Zugang zu den HTML-Webchats immer weiter erschwerten, schwieriger nutzbar und dadurch unattraktiver geworden. --193.159.112.36 00:06, 7. Jun. 2011 (CEST)