FileAPI: FileReader
FileReader- und FileWriter-Objekte greifen über die Browser-Sandbox hinaus auf die lokale Festplatte zu. Es ist schließlich ein Unterschied, ob sie nur die Möglichkeit haben, pro Session Daten abzulegen oder ob sie darüber hinaus Funktionen wie readAsBinaryString verwenden dürfen. Die FileAPI ist noch nicht weit verbreitet, schickt sich aber an, die Grenzen zwischen "persönlichem" (Festplatte) und "öffentlichem" (Internet) Teil des PCs einzureißen. Es existieren bereits Ansätze, in den Browser eingegeben URIs wie file://C: mehr wie Websites aufzulösen. JavaScript soll durch einheitliche XML-http-Request-Anfragen weniger stark zwischen lokalen und serverseitigen Daten unterscheiden.
Die API-Details sind noch nicht ausgearbeitet. Die Spezifikation ist voll von nützlichen Vorschlägen, wie dem, dass systemrelevante Dateien (wie /usr/bin-Verzeichnisse, Passwortdateien, EXE-Files) diesem Zugriff entzogen bleiben sollten. Wichtig ist dabei das Wort "sollten" - es wird in der Tat im Konjunktiv verwendet. Der W3C-Vorschlag geht dahin, dass der Browser bei Zugriffsversuchen auf derartige Dateien einen "Security Error" ausgibt. Bis es aber einen FileReader-Standard gibt, wird es noch dauern.
FileAPI: FileWriter
FileWriter ist das Gegenstück zum FileReader - die API könnte unter anderem die Installation neuer Software stark vereinfachen. Zunächst wird ein Block mehrerer Bytes erstellt (Blob) und in ein FileWriter-Objekt umgewandelt. Anschließen können Rechte wie "append" oder "write" vergeben werden, die es dem Objekt erlauben, auf der Festplatte der Anwender zu wildern. Ein Paradies für Virendesigner - die sogar noch wählen dürfen, wie sich Ihre Werke installieren sollen.
Natürlich muss es nicht soweit kommen, und wenn die Modelle so arbeiten wie vorgesehen, wird es das auch nicht. Momentan sieht es danach aus, dass der Anwender vom Browser vor jedem Schreibzugriff gefragt wird, wo Daten abgelegt werden sollen - sensible Festplattenbereiche werden dabei wohl von vornherein kategorisch ausgeschlossen. Doch schützt das vor Schäden? Die größte Gefahr sitzt schließlich vor dem Rechner.
Offline-Web-Anwendungen: AppCaching
Indem Web-Seiten Dateien lokal speichern dürfen, kann sich der Netztraffic erheblich reduzieren - weil AJAX-Abrufe und anderes zwischengespeichert werden. Das Caching der Website selbst ist davon aber kaum beeinflusst. Die AppCaching-Entwicklungsumgebung sorgt deshalb dafür, dass Teile der Seite lokal zwischengespeichert werden. So werden zum einen die notwendigen Reloads minimiert und sind zum anderen Sites möglich, die auch ohne aktive Internet-Verbindung weiterarbeiten. Auch jetzt schon können HTML-Seiten mit Header-Tags ausgestattet werden, die ein solches Caching möglich machen - JavaScript- und CSS-Erweiterungen (Cascading Style Sheets) sind davon jedoch nicht erfasst. Die AppCaching-API erzeugt deshalb für jede Seite ein eigenes Ladeverzeichnis, in dem alle wichtigen Seitenteile aufgelistet sind, und gibt es an den Browser zum Auslesen weiter. Voraussetzung ist folgender Eintrag im Header Code:
<html manifest="page.manifest">
Der Browser schaut sich daraufhin das Ladeverzeichnis an und behandelt alle erfassten Dateien zusammen als eine Einheit. Sobald sich das Ladeverzeichnis ändert, lädt der Browser die gesamte Website neu.
Die API behandelt die Elemente unterschiedlich: So können Abrufe von serverseitigen CGI-Funktionen beispielsweise in einen separaten Teil des Verzeichnisses ausgelagert werden, um ihr Caching zu verhindern. Auch gibt es eine allgemeine Fallback-Sektion, in der Anweisungen für den Fall aufgeführt sind, dass bestimmte Teile nicht zwischengespeichert werden können. So lassen sich dort beispielsweise Alternativ-Icons für nicht verfügbare Bilder angeben.
Auf der folgenden Seite finden Sie Näheres zu den noch nicht weiter ausgearbeiteten Plänen über versteckte Dateien im HTML-Baum und neue maschinenlesbare Metainformationen...