Dark Guardian

Eine bestehende Verbindung zum Server hätte shcon Vorteile.

Performanceprobleme sehe ich da nicht. Auch kein großs Problem ein Browserplugin zu schreiben und eine dazu passende Serversoftware welche diese Funktionalität bietet.

Den eigentlich Vorteil sehe ich darin das der Server mit dem Client kommunizieren kann und nicht nur der Client mit dem Server. D.h. solange eine Anwendung geöffnet bleibt kann der Server dem Client neue Informationen zukommen lassen ohne das eine Interaktion des Benutzers nötig wird.

Also Dinge die heutzutage mit Flash oder Java gelöst werden (quasi Socket-Verbindungen).

Verbindungstimeouts kann der Server ja anch wie vor slebstständig erkennen. Oder eben anch 30 Minuten eine Nachricht an den Browser senden, diese wird dort angezeigt und danach kappt der Server die Verbindung.

Vorteil gegenüber Desktopanwendungen wäre die Flexibilität von Webseiten und die Servergesteuerte Ausführung des Codes. Der Browser stellt nach wie vor nur das dar was der Server ihm mitteilt.

__________________
"Alles im Universum funktioniert, wenn du nur weißt wie du es anwenden musst".

Mister Ad

hts

Und in Zukunft halt HTML5-WebSockets.

Manko10

Micht stört ehrlich gesagt ein wenig, dass das alles unter HTML5 geführt wird. Weder Canvas-Programmierung noch LocalStorage noch WebSockets haben irgend etwas mit HTML zu tun. Das sind alles von der ECMA-Spezifikation unabhängige JavaScript-Erweiterungen.
Man hatte sich mal darauf geeinigt, die drei Schichten zu trennen: Struktur, Gestaltung, aktive Inhalte, aber seit HTML5 ist davon irgendwie nicht mehr viel übrig.

__________________
Refining Linux Advent Calendar series “24 Outstanding ZSH Gems”

nikosch

Klingt nach einem optimalen Spam- und Werbekonzept. Ich finds eigentlich gut, die Kontrolle zu haben, was mein Browser anfordert..

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Flor1an

Vorteile hat es sicherlich wenn man ein Protokoll hätte das nicht "stateless" ist. Aber ich denke schon das du eher Performanceprobleme bekommen könntest. Z.B. wenn du nen Apache her nimmst. PHP braucht für nen Skript Ablauf vlt. 5mb vom Arbeitsspeicher (teils sogar noch bedeutend mehr). Wenn du jetzt pro Verbindung nen eigenen Child-Prozess im Apache starten musst und diese alle 5mb haben kannst du dir gut ausrechnen wie viele maximale Verbindungen du gleichzeitig offen haben kannst. Kommt dann ein neuer Besucher, kann er sich überhaupt nicht mehr mit dem Server verbinden!

Dark Guardian

Naja, was aus der gegebenen Technik gemacht wird ist wieder ein anderes Thema. Du könntest theoretisch auch via JS pemanent Werbung nachladen wenn JS nicht deaktiviert ist.

Den Apache dafür zu nutzen halte ich auch nicht für sinnvoll weil der Apache für das HTTP Protokoll ausgelegt ist und nicht für TCP/UDP Verbindungen ODER was auch imemr für ein Ptrokoll welches auf TCP aufsetzt für so etwas entworfen werden könnte.

__________________
"Alles im Universum funktioniert, wenn du nur weißt wie du es anwenden musst".

nikosch

Leider ist es aus jahrelanger Erfahrung für uns alle eine Gewissheit, dass Spammer, Betrüger und Werbetreibende immer die ersten bei solchen Technologien sind. Von daher bin ich immer vorsichtig mit solchen Wünschen.

Jeden Client identifizieren zu können, wäre aus Applikationssicht auch ein Segen, aus Clientsicht leider genau das Gegenteil.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--