Re: [dpub-loc] Draft update

On Fri, Feb 12, 2016 at 9:13 AM, Ben De Meester <ben.demeester@ugent.be> wrote:

> Line 60
>>    * If the preferred state is the packed one, then **Lp** accessed,
>> unpacked, and the image is localized within the unpacked content (and that
>> usually means using the relative URL as some sort of a file system path
>> within that unpacked content)
>
> _To be clear, this means the PWP on **Lp** is downloaded entirely and the
> image is retrieved client-side, right? I agree that this is a viable
> solution, with minimal server requirements. But if your server is smarter,
> it can retrieve that image client-side and return that image directly. Do we
> need to fix that functionality as either client-side or server-side? Can't
> we just define functionalities and let implementers implement as they see
> fit? Or is that just crazy talk? :)_
>

Note that it is possible to download only fragments of a packed
publication, without any server-side code ; just by emitting HTTP
partial byte-range requests from the client-side. It is therefore
possible to acquire individual files from the archive directory of a
publication hosted remotely, by inflating / unzipping streams of
binary data into Blob-URIs, or even better: by channeling them into
ServiceWorker's response payloads (as a result of intercepting "fetch"
events). Either way, the mime/content-type ; which is necessary for
the browser to interpret the resource correctly ; can be obtained from
the publication's "manifest".

Readium uses this technique to read files from packed EPUBs. In case
of failure to acquire partial chunks of data (e.g. because of missing
HTTP CORS Content-Length header), then the fallback is to download the
full .epub archive. The experimental implementation of ServiceWorker
in Readium relies on this mechanism, so that the browser iframe "sees"
a packed EPUB as if it were already exploded / unzipped. The trick
used is a URL syntactical convention based on the ! exclamation mark
(as per the JAR standard), denoting a level of indirection into the
EPUB archive (e.g. https://domain.com/ebook.epub!/path/to/image.png).
In other words, the "base" URL (leftmost part of the full resource
locator) is https://domain.com/ebook.epub instead of
https://domain.com/ebook/  (that being said, SW allows building HTTP
responses to pretty much any "fake" URL request, so this is just an
implementation detail)
For those of you who like to see dirty code:
https://github.com/readium/readium-js/blob/feature/ServiceWorker/js/EpubServiceWorker.js

Regards, Daniel

Received on Friday, 12 February 2016 10:48:27 UTC