molily: Application Cache - Fonts (Formate)

Beitrag lesen

Das eigentliche Problem besteht (mal wieder) darin, dass man serverseitig nicht die nötigen Infos hat, um bspw. das Manifest entsprechend on-the-fly zusammenzustellen.

Das Grundproblem ist vielmehr, dass ein deklaratives Manifest den Ansprüchen heutiger Webapps nicht genügt. Sie laden Daten gemäß einer komplexen Logik, die sich nicht so einfach deklarativ ausdrücken lässt. Ich denke nicht, dass man dem mit Headern beikommen kann. Dieses Modell skaliert nicht. Wie sollte man irgendwelche JavaScript-Fähigkeiten, die ein Polyfill benötigen oder nicht, in einem Header ausdrücken? Das kann nur in JavaScript geschehen.

Soweit ich das richtig verstanden habe, lädt der Browser "alle" Resourcen einer Seite aus dem Application Cache, sofern einer für die entsprechende Seite vorhanden/ angegeben ist.

Ja, allerdings im Hintergrund, soweit ich weiß, also die Seite lädt dadurch nicht unbedingt langsamer. Unschön ist die Datenmenge trotzdem.

Wie sieht das denn dann aus, wenn man im Manifest in der Network Sektion einen '*' einträgt, was dem Browser ja erlaubt, alle fehlenden Resourcen über das Netz nachzuladen. Holt er dann diese Resourcen nicht ggf. aus seinem "normalen" Cache?

Ja, soweit ich weiß. Das Manifest setzt den normalen Cache nicht außer Kraft. NETWORK heißt nicht, dass ein Request erzwungen wird, er kann auch aus dem Cache bedient werden.

Im Moment erscheint mir eine Variante, die Local Storage verwendet da fast besser geeignet zu sein, als der Apllication Cache. Denn dieser besitzt imho zu viele Nachteile, bzw. Unzulänglichkeiten.

Das ist glaube ich Konsens. ;)

Wobei localStorage und IndexedDB noch keinen Sync-Mechanismus und kein Asset-Management mitbringen. Die müsste man selbst entwickeln. PouchDB geht in eine solche Richtung, wobei es weniger für Assets gedacht ist.

Mathias