Im ersten Teil der HTML5-Serie konnten Sie alles über neue Präsentationsformen im multimedialen Bereich lesen. Im zweiten Teil beschäftigten wir uns mit den neuen Möglichkeiten zur Datenaufbereitung sowie zur Verknüpfung von Online-Diensten und lokalen Anwendungen. Im dritten Teil soll es weiterführend um neue Methoden der Datenübertragung gehen.
Die Kommunikationswege eines Web-Browsers waren schon immer unergründlich. Einerseits gefällt die Idee einer alleinstehenden, durch den Browser kontrollierten "Sandbox", die größeren Schaden auf der lokalen Festplatte verhindert - es ist kaum möglich, Schädlinge aus dem Netz mit nur einem Klick auf die Gesamtheit der stationär gespeicherten Daten loszulassen. Andererseits beschweren sich Entwickler immer über diese Restriktionen - die Möglichkeiten, die sich eröffneten, wenn der Browser mehr sei als "nur" ein Zugangsort zum WWW, seien schließlich kaum auszumalen. Gerade AJAX-Programmierer zeigen sich betroffen und fordern, die Zugriffsregeln zwischen Sandbox und Browser zu lockern.
Mit HTML5 soll sich der Blick auf das digitale Kommunikationsverhalten grundlegend ändern - zugunsten der Entwickler. Die eisernen Gesetze sollen jedoch weitestgehend ohne Kollateralschäden aufweichen können - die Devise lautet: flexiblere Technologie, gleich bleibende Sicherheitsstandards.
Die Modelle und Methoden, die HTML5 anbringt, dürften den meisten Programmierern bekannt vorkommen - sind sie doch weitestgehend Erweiterungen bereits bekannter Ideen. So setzen beispielsweise GUI-Entwickler häufig auf Schaltflächen und Reiter, um Aktionen innerhalb eines Codes hin- und herzuschieben - diese "Listener" genannten Seitenelemente sind zwischen den Aktionen im dauerhaften Wartezustand auf die nächste Aktion. HTML5 trägt das Konzept weiter und schaltet verschiedene Websites über einen Tunnel zusammen, um Code untereinander auszutauschen - es läuft also nicht mehr jede in ihrer eigenen Sandbox. Die Sandboxen werden dafür nicht miteinander verschmolzen, sondern kommunizieren gleichzeitig über denselben Kanal.
Komplexität verringern
Der Nutzen ist offensichtlich: Programmierer, die ständig bemüht sind, die Gefahr von Webattacken wie Cross-Site-Scripting möglichst gering zu halten, erhöhen mit jedem zur Gefahrenabwehr entwickelten Hack auch die Komplexität des Codes sowie den Netztraffic. Einige Websites schalten serverseitig einen Proxyserver vor, um die Probleme auszuschalten. Die neuen HTML-Spezifikationen greifen den Entwicklern nun unter die Arme: keine Geschwindigkeitseinbußen durch komplexeren Code mehr.
Der erste Bereich, in dem die neu entstandenen Möglichkeiten zum Einsatz kommen könnten, ist möglicherweise die Werbung. Dort wie bereits länger versucht, durch das Zusammenspiel verschiedener Site-Ebenen mehr Aufmerksamkeit beim Anwender zu erzeugen. Die Verlinkung mehrerer Prozesse untereinander macht nun eine Interaktion zwischen Widgets, RSS-Feeds und anderen Datenkanälen verschiedener Fenster möglich. Wie genau das aussehen kann, zeigen unter anderem Yahoo Pipes-Mashups, die verschiedenste Quellen miteinander rekombinieren. In diesem Fall bewerkstelligt der Server die meiste Arbeit, während HTML5 dem Client nur einen kleinen Teil der Verantwortung zubilligt. Yahoo Pipes ist voller Mashups, die RSS-Feeds in interaktive Karten und andere Dienste übertragen. So verbindet eines die Filmkritiken von einer Website mit den entsprechenden Kinotrailern aus einem anderen Angebot.
Im Folgenden stellen wir die wichtigsten HTML5-Neuerungen für Interlayer-Kommunikation vor.
Von Webdokumenten zu Web-Applikationen
Das ursprüngliche Konzept eines Webdokuments sah ein Dokument mit Wörtern und Bildern vor - eingerahmt in ein einziges Rechteck. Im Laufe der Zeit wurde das große Rechteck zwar in viele kleine, mit anderen Hintergrundfarben versehene Rechtecke unterteilt - in allen gab es aber nach wie vor Wörter und Bilder. Da war nicht viel zu spezifizieren. Heute sind Dokumente dank AJAX-Funktionen eher als Software einzustufen - und Software macht sich bemerkbar. Das "Leben" in den Browserfenstern sollte nach dem Willen vieler Programmierer nicht auf jeweils ein Fenster respektive jeweils nur alle Fenster eines Webangebots beschränkt bleiben - warum nicht die Box mit dem Inhalteangebot und die Box mit der Werbung seitens Google AdWords miteinander verknüpfen? Oder warum nicht noch mehr Nutzen aus Widgets ziehen, die beispielsweise Blogger auf ihre Online-Tagebücher satteln, um den Besuchern Wettervorhersage, Spielstände oder Kinozeiten anzuzeigen?
Datentransfer über mehrere Dokumente
Das Entwicklerteam hinter HTML5 bricht eine Lanze für die Idee des Datentransfers über mehrere Dokumente hinweg. Die angesprochenen Rechtecke bauen einen Kommunikationskanal auf, indem sie mittels Quellcode Listener erstellen, die auf Nachrichten anderer Rechtecke warten respektive selbst Nachrichten verschicken - ganz ohne zentralen Server. Die verantwortliche API sorgt dafür, dass der Transfer auf bestimmte Domains beschränkt wird. Es ist nicht möglich, Nachrichten an alle potenziellen Listener zu senden. Der Entwickler legt fest, welche Fenster und Dokumente angesprochen werden. Für einen dauerhaften Austausch legt er Zweiwegekanäle an.
Die Listener-Spezifikation ist noch in der (instabilen) Betaphase, wird aber von nahezu allen Browsern schon unterstützt (Chrome, Firefox, IE, Opera, Safari). Da jede Software mit einer ähnlichen Interlayer-Kommunikation arbeitet, ist es nur eine Frage der Zeit, bis sich das Prinzip auch bei den Entwicklern auf breiter Ebene durchsetzt. Wer seinen Browser testen möchte, kann das hier tun.
Ressourcen-Sharing
Nachrichten zu verschicken ist nicht der einzige Weg, Informationen zwischen Websites auszutauschen. Die API für "Cross-Origin Resource Sharing" (cors) lockert die Kontrolle über AJAX-Befehle und erlaubt jedem außerhalb der Home-Domain den Zugriff. Eine Website kann so eine Liste erlaubter Ziele festlegen, und die XMLHttpRequest-Anfragen sollten funktionieren. Die Informationen darüber stehen im Header des HTML-Dokuments. Damit der Server sie verarbeiten kann, muss er deshalb rekonfiguriert werden - eine Aufgabe für den Administrator, nicht für den Entwickler:
Access-Control-Allow-Origin: http://infoworld.com [9] Access-Control-Max-Age: 10000 Access-Control-Allow-Methods: PUT, DELETE
Dieser Eintrag erlaubt es einer Website, zusätzliche Daten von infoworld.com zu holen und anzuzeigen, die maximal 10.000 Sekunden alt sind.
Neue WebSockets-Spezifikationen sorgen für mehr Interaktivität im WWW. Alles dazu lesen Sie auf der nächsten Seite.
WebSockets
Wenn AJAX-Befehle lange brauchen, um vollständig ausgeführt zu werden, gehen sie meist mit einem Time-out zu Ende. Diese Fehlermeldungen wären für Aufgaben wie das Einsammeln der aktuellen Nachrichten ja noch akzeptabel - für interaktive Websites, die ein schnelles Server-Pinging voraussetzen, ist das jedoch nicht zu empfehlen. Um nicht ständig in regelmäßigen Zeiträumen einen Ping an den Server senden zu müssen, um Informationen aktualisieren zu können, wurde das auf TCP basierende WebSocket-Protokoll erfunden, das eine bidirektionale Verbindung zwischen Webanwendung und Web(Socket)-Server herstellt. Wo TCP Daten nur dann aktualisiert, wenn ein erneuter Ping ausgeführt wird (Pull-Verfahren), hält WebSockets die Verbindung die ganze Zeit aufrecht und kann neue Daten in Echtzeit überspielen (Push-Verfahren). Mit HTML5 wird die WebSocket-API an den Quellcode angebunden. Chrome, Firefox, Opera und Safari unterstützen WebSockets bereits - die meisten Webserver hingegen noch nicht, weshalb die Möglichkeiten keinesfalls schon nutzbar wären. Ein Beispiel für ein bereits entsprechend eingerichtetes WebSocket-Gateway-Angebot ist Kaazing.
Aber auch eine WebSocket-Verbindung ist nicht ewig stabil, von ihren Sicherheitsproblemen ganz zu schweigen. So haben Google und Mozilla die WebSocket-Unterstützung in ihren Browsern derzeit abgeschaltet, nachdem es Forschern gelungen war, über WebSockets Malware in den Browser-Cache zu laden. Die von den Wissenschaftlern vorgeschlagene Verbesserung des Browser-Codes an dieser Stelle wird von den Herstellern gerne angenommen. Bereits jetzt lässt sich die WebSocket-Unterstützung im Firefox mit wenigen Handgriffen wieder einschalten - wenn auch zunächst nur zu Testzwecken. Es wird aber nicht lange dauern, bis sich das Protokoll mit Hilfe von HTML5 auf breiter Front durchsetzt.
Server-sent Events
Dass der Client Daten vom Server abholen kann und sich mittels WebSockets Informationen in beide Richtungen transportieren lassen, wissen wir nun. Fehlen noch die server-sent events, die es dem Server erlauben, einseitig und ohne Rückfrage beim Client Daten zu versenden und Funktionen auszuführen. Dazu bedarf es erst eines EventSource-Objekts, das die Domain anzeigt. Im zweiten Schritt der Implementierung wird eine Funktion registriert, mittels der die Events im "If"- und "When"-Modus verarbeitet werden. Dazu braucht es keinerlei offener Sockets oder ständiger Anfrage bei einem anderen Server. Gerade auf mobilen Geräten sind die server-sent events sinnvoll, um Energie zu sparen.
Ein einfacheres Web
Sowohl Web-Entwickler als auch ISPs dürften von den verbesserten Kommunikationskanälen profitieren. Der Bedarf an massivem Datenverkehr sinkt und die Geschwindigkeit der Web-Angebote steigt. Lediglich die Gretchenfrage nach der Sicherheit bleibt. Diese liegt in der Verantwortung der Serverbetreiber, da die vorgestellten Features von der Anwenderseite aus nicht beeinflusst werden können. Unterstützt ein Web-Server einige oder alle, hat der Nutzer dies mitzutragen - unterstützt er sie nicht, ebenfalls. Vielleicht ändert sich das, sobald ihr Missbrauchspotenzial aufgezeigt wird - die Hacker stehen bereits in den Startlöchern.
Der Artikel stammt von Peter Wayner von unserer US-Schwesterpublikation InfoWorld. Die HTML5-Reihe wird fortgesetzt. (sh)