iframe loader, resource / publication fetcher => vendor-specific configuration (RequireJS Grunt overrides?)

[danielweck]

This seems like a reasonable candidate for the upcoming refactoring, either via the introduction of a new plugin mechanism (extensibility API) ; or simply by leveraging the existing RequireJS dependency injection framework ; thereby ensuring that the existing "useSimpleLoader" and "shouldConstructDomProgrammatically" + "shouldFetchMediaAssetsProgrammatically" (etc.) parameters can be controlled at build time (vendor-specific Grunt script overrides), in addition to the runtime decision tree (as the choice of loader / fetcher depends on the nature of EPUB to open, see comment below for details).

https://github.com/readium/readium-js/blob/develop/epub-modules/epub-fetch/src/models/publication_fetcher.js#L88

https://github.com/readium/readium-js/blob/develop/epub-modules/epub-fetch/src/models/iframe_zip_loader.js#L36

https://github.com/readium/readium-js-viewer/blob/develop/chrome-app/extended-config.js#L23

[jansc]

I would prefer if these options were available at run-time and not at build time. Our use case for this is a library with books from different sources, both online and offline. I'd like to configure shouldConstructDomProgrammatically and shouldFetchMediaAssetsProgrammatically depending on the book to be read.

[danielweck]

Hello @jansc sorry my description was misleading (now fixed), as indeed the choice of "loader" + "fetcher" depends on the nature of the EPUB to open, and occurs at runtime. For example, right now this is the decision matrix:

Goal reminder: pre-process HTML files to inject the navigator.epubReadingSystem object instance, the MathJax Javascript library, and some annotation-related CSS (as a result, this functionality is bootstrapped in EPUB content documents before the window.onload / DOMContentLoaded / ready event)

1) normal loader (feeds the iframe with a http:// or filesystem:// URI) => native apps (HTML files are processed on-the-fly during inflation from zip archive, fonts are also de-obfuscated on demand) => Chrome extension (HTML files are processed during unpacking, prior to being stored in local file system, fonts are also de-obfuscated before becoming persistent in storage)

2) special loader (feeds the iframe with a blob representing the pre-processed version of the original HTML) => cloud reader 2.1) full publication resource fetcher (every asset dependency such as images, CSS, fonts, Javascript, etc. are programmatically resolved / pre-loaded as binary Blob URIs) => zipped EPUBs => expanded EPUBs that contain obfuscated fonts 2.2) HTML resource fetcher (only the HTML gets pre-loaded, the linked assets are resolved automatically by the web browser from the base URI) => expanded EPUBs that do NOT contain obfuscated fonts

@jansc do you require any additions / alterations to this processing model?

[jansc]

I'm not sure if I understand your list of loaders. What I want is probably a variant of 2.1 pluss an unmodified 2.2. 2.1:

• zipped EPUBs
• expanded EPUBs w/obfuscated fonts
• expanded EPUBs from any storage where a plugin/user specified code can supply blobs on demand. Maybe that should simply be "expanded EPUBs without obfuscated fonts"

Sorry if I misunderstood your suggestion.

[danielweck]

Okay. So it looks like all the functionality you need is available in the current Readium codebase, but we need to address some architectural issues. PS: what would you use the "blobs on demand" for? Do you need to implement custom pre-processing steps? (to modify HTML content before passing it onto the webview control?)

[jansc]

Yes, that's right. Our use case for BLOBs on demand is that we want to implement offline storage of unzipped EPUBs in web browsers which don't implement the Filesystem API (= IE, Firefox, Safari). We'd also like to use custom preprocessing to implement media enrichments and some EPUB Widget experiments to include other learning resources. EDIT: I guess that pull request #82 could also be solved by extending the fetcher architecture.

[kimtuck]

Hi everyone, I have written a plugin for resource fetching that allows you to create your own resource fetcher; I'll be posting that as a pull request in a couple of days. Take a look and see if that can address this issue; or serve as a starting point anyway.