Access of local files from the service worker

[iherman]

As discussed at the Sapporo F2F some additional information/note should be added to the PWP document.

/Cc @danielweck

[iherman]

One trick (done by Readium) is always launch a web server locally that 'hides' the file system and HTTP (and HTTP is o.k. on local host) (per comment of @danielweck at the F2F)

[danielweck]

@iherman let me rephrase your statement about Readium :)
Long, more accurate version:

HTTP:

• Readium "web/cloud reader" is a client-side app (i.e. no server-side code, at all) designed to be served via HTTP and to execute in the browser. The app fetches EPUB contents from the same HTTP domain, or from different origins (CORS headers). XmlHTTPRequests are used to load assets from exploded / unzipped EPUBs, or packed / zipped archives. Service Workers is useful in this latter context, to transparently "stream" file resources from within the EPUB archive, i.e. to build response payloads for web-view URL requests such as http://domain.com/ebook.epub!/META-INF/container.xml (for illustration only ... the ! syntax expresses a level of indirection into the ZIP archive's file tree). The usual SW "restrictions" apply: secure HTTPS, domain scope for fetch events, etc. However, it seems that SW is happy with unsecured HTTP when running the app on a local IP (this is how we're testing our SW experiments, so far we haven't actually tried "proper" HTTPS deployment yet).

FILESYSTEM:

• The Readium Chrome extension (which is effectively a Chrome "packaged app") never reads packed / zipped EPUBs directly: they are expanded into local file storage (HTML5 Filesystem) prior to reading, and each extracted file is associated with a distinct URL using the filesystem:// scheme. The app itself is served via the chrome-extension:// URL protocol. Service Workers could potentially be useful in this context too, for example for on-the-fly content modifications, decryption, etc. I do not know if the filesystem:// / chrome-extension:// schemes are supported by Service Workers though? (I haven't checked)

FILE:

• The aforementioned Readium Chrome app can actually be packaged in an hybrid app framework, such as Electron (Atom Shell). In that case, the app itself is served via the file:// URL scheme, and the EPUB content via filesystem://. Again, no idea whether Service Worker can be used in this context.

Note about Readium "native" apps: @iherman you are correct, in this case an embedded HTTP server ensures that the content is served to the web-view via HTTP, but the app itself can be hosted on the HTTP server, or served via file:// (typical application "bundle" location on the filesystem). Either way, Service Workers are not really needed in the context of native apps, because most of the file-to-webview logic is handled "natively".

[iherman]

@danielweck, thank you. The question is, in your experience based on Readium, whether the issue around local files, the general model and approach, the effect in terms of PWP, etc, can be made better and more precise in the PWP document. I admit that, in the current version, it is a bit of a handwaving... I would greatly welcome some better text there. (Not for the draft we'll publish in a few days, but for the next versions...)