HTML5 auf dem Desktop: Ansätze für RIAs

Ich habe vor Kurzem das GRW eines neu erschienen Rollenspielsystems in die Finger gekriegt. Nachdem ich bereits ein verlagsseitig geliefertes Spreadsheet zur Charaktererstellung aufpoliert habe, spiele ich jetzt mit dem Gedanken, eine Charakterverwaltung zu programmieren.

Natürlich sind Charakterverwaltungen keine irrsinnig komplexen Programme. Prinzipiell könnte ich das mit HTML5 und JavaScript relativ einfach umgesetzt kriegen, wenn da nicht ein nerviges Problem wäre: Javascript hat keinen Zugriff auf das Dateisystem und auch die HTML5 File API kann Dateien nur lesen und nicht schreiben.

Daraus hat sich für mich eine allgemeine Frage ergeben: Welche Möglichkeiten habe ich, eine HTML-basierte Anwendung lokal zu betreiben und die Daten zu speichern? Natürlich sollte die Anwendung auf allen Desktop-Plattformen funktionieren und jegliche Abhängigkeit von Onlinediensten ist sofortiges Ausschlußkriterium.

Ich weiß, daß ich localStorage benutzen kann, aber localStorage ist browsergebunden und idR. auf maximal 5 MiB beschränkt. Das ist okay für Autosave, aber nicht für allgemeine Arbeit.

Es gibt die Möglichkeit, ein Flash-Applet einzubinden, das nichts anderes tut, als eine Datei zu schreiben. Dummerweise brauche ich dann Flash und das Applet könnte je nach Browserkonfiguration nicht mal sofort verfügbar sein.

Als Letztes fällt mir noch XULRunner ein. Wenn ich nicht vorhabe, mich mit XUL zu befassen, könnte ich einfach einen Browser-Viewport über die ganze Größe der Anwendung aufmachen und meinen Kram darin anzeigen; speichern würde ich dann (sofern möglich) über XUL-Hooks im JS.


Übersehe ich etwas? Gibt es ein Framework, mit dem ich den Kram einfach gemacht kriege? Oder ist letztenendes Java weiterhin das Nonplusultra für plattformübergreifende Desktopanwendungen?

Gut, du hast natürlich immer noch die Möglichkeit, dem Benutzer einen Data-Link anzubieten, den er anklicken kann, um den Inhalt mit der Speicherfunktion vom Browser zu speichern.

Das Ganze geht natürlich auch ohne Link zum Anklicken, indem man mit location.href den Browser entsprechend nach "data:application/octet-stream,Whatever" umleitet.

Hmm. Mit IE8 nur kompatibel, wenn man nicht mehr als 32 KiB Daten erzeugt, aber prinizipiell geeignet. Danke; da hatte ich nicht dran gedacht.

Oh nein. Um Wikipedia zu zitieren: "In IE 8 and 9 data URIs can only be used for images, but not for navigation or Javascript generated file downloads."

Danke, Microsoft.

Zitat:

---

Zitat von Jesus_666

Hmm. Mit IE8 nur kompatibel, wenn man nicht mehr als 32 KiB Daten erzeugt, aber prinizipiell geeignet. Danke; da hatte ich nicht dran gedacht.

Oh nein. Um Wikipedia zu zitieren: "In IE 8 and 9 data URIs can only be used for images, but not for navigation or Javascript generated file downloads."

Danke, Microsoft.

---

Wahrscheinlich hatten Leute angefangen, spezifisch für IE-Nutzer komplette Firefox-Binaries in data:-URLs zu stecken. XO

Man kann natürlich Conditional Comments benutzen, um auf IE <= 9 zu prüfen und dann statt Downloads ein Textfeld anzeigen, wo ein arschlanger Base64-String angezeigt wird, den man dann von Hand rauskopieren darf.

Die Daten HTML zu formatieren ist sicher nicht schön aber durchaus machbar. Dann könnte man die normale Speicher-Funktion des Browsers nutzen.

Wobei, wenn lediglich IE <= 8, die Hürde für nen data-link ist, das oder die String kopiererei ja durchaus eine Variante ist.
(Mal ehrlich: In welchem halbwegs realisitischen Szenario kann dieser benutzer keinen Browser auf seinem System installieren?)

Dafür brauchst du ja nichtmal HTML. Der Browser kann ja auch alle möglichen anderen Dateien speichern/zum Download anbieten.

Naja, "Speichern als..." würde voraussetzen, daß ich den gesamten Inhalt der Seite mit nichts anderem als dem Dokument ersetze (oder jedes gespeicherte Dokument enthält eine unvollständige Kopie der Anwendung). Das ist nicht gerade optimal.

Nebenbei habe ich zwischendurch noch einen Problembrowser gefunden: Safari. Apple hat sich nie die Mühe gemacht, die FileReader-API zu implementieren und so kann man für Safari-User keine Ladefunktion bereitstellen.


So langsam bin ich überlegen, ob es nicht einfacher wäre, den Kram teilweise in XUL zu implementieren. Man kann einem XULRunner sicher irgendwie einen Browser-Viewport geben, der mit internen Funktionen wie dem Dateisystemkram sprechen kann. Das wären dann zwar wieder plattformspezifische Downloads, aber die belaufen sich darauf, jeweils eine andere XULRunner-Binary zu bundlen.

Und immerhin hätte man den Vorteil, nur gegen einen Renderer bauen zu müssen.