A sample implementation of a resource fetcher plugin. This plugin of… #350
Conversation
…ers a reference implementation only; modification and testing in your environment is encouraged. This resource fetcher calls out to an API endpoint to get the desired resource.
|
Great, thank you! |
|
Hi Daniel, I want to give you some background on these various pull requests and issues that I’ve posted. Bibliotheca (http://www.bibliotheca.com) is a leading provider of both physical and ebook solutions for public libraries around the world. The ebook solution used to be a business unit of 3M; until it was purchased about a year ago by Bibliotheca. For the last year or so I’ve been working on adding ebook reading capabilities to our web-based patron solution. Most of the work involved building a UI wrapper (a replacement for the readium viewer, if you will) that has the same look and feel as the rest of the web app; calls out to our API for things like login validation. We have access to a wide range of epub books from many different publishers. As you can imagine, some of the books have revealed behavior in readium that needed to be addressed in order for us to release our reader to production. The Bibliotheca web reading solution should go live on Monday (!!!) I implemented those fixes as patches to the readium code and made them part of my source tree. I’ve included all of those patches as pull requests, with the hope that they get merged into the master release of readium at some future point in time. Another of our requirements is that the content of an epub is protected as much as possible, so that a casual user can’t download entire books or sections of a book. To facilitate this, we have a private epub repository; and a service that provides an API to get content from an epub located in the repository. The API encrypts the contents sent over the wire; and the client decrypts the contents before handing them to readium. To facilitate this, I created the ability to provide a resource fetcher plugin. It seemed the simplest way, and keeps the readium code from getting too cluttered. Lastly, and maybe most important, is that my contract here at Bibliotheca is coming to an end, at the end of November. I wanted to make sure that my work gets back out to the community before I leave. I’d like to continue to contribute; and I will as time permits. I’m sure that Bibliotheca will continue to contribute as well. We can certainly provide feedback and give you epubs that illustrate issues or improvements that we find. Robert Hanson (kimtuck) |
| // It's based on a plugin used at Bibliotheca to get the contents of an epub from a server. I've edited this file to remove | ||
| // some functionality specific to Bibliotheca. The result may or may not be suitiable for your needs. | ||
|
|
||
| define(['readium_js_plugins', 'readium_shared_js/globals', '../../../js/epub-fetch/discover_content_type' ], |
There was a problem hiding this comment.
../../../js/epub-fetch/discover_content_type
https://github.com/readium/readium-js/blob/develop/js/epub-fetch/discover_content_type.js
This reference is problematic, because code in readium-shared-js cannot make assumptions about its integration context. This dependency injection assumes that readium-js is the parent repository (that readium-shared-js is a submodule). ReadiumSDK-based native apps also make use of readium-shared-js, but have absolutely zero-awareness of readium-js.
Now, this issue is mitigated by the fact that in practice, the ResourceFetcherPlugin would only ever be used in the context of an app that relies on readium-js. But generally-speaking, there is definitely a problem in readium-shared-js plugins having dependencies from external RequireJS namespaces (../../../js/epub-fetch/discover_content_type is of course equivalent to readium_js/epub-fetch/discover_content_type, but this syntax would only work when building from readium-js or readium-js-viewer, not from within readium-shared-js).
There was a problem hiding this comment.
PS: the point I am making here is that Readium "plugins" were originally designed (minimally) for usage within the readium-shared-js scope. So some architectural hacks are required to implement plugins for readium-js, etc.
@jccr
|
Robert (@kimtuck), thanks for the clarifications, and for sharing your ideas / code. |
This pull request is a Sample Implementation
Related issue(s) and/or pull request(s)
There will shortly be a pull request that allows readium to support Resource Fetcher Plugins; that code needs to be merged in for this sample to be useful.
Test cases, sample files
Additional information
The Bibliotheca hybrid app gets the contents of epubs by making api calls to a server; the payload of the request is a list of one or more files that readium needs to get from the epub. The server opens the epub, extracts the required files, and sends them over the wire back to the client. When the client receives the files, the appropriate callbacks are executed with the contents of the file.
Bibliotheca uses a plugin to provide this functionality. (The plugin code is considered intellectual property, so is not included here). The plugin offers the capability of over-the-wire content encryption, file request batching, and request retry on failure.
This sample implementation of a resource fetcher plugin shows a simple call to an API. This plugin offers a reference implementation only; modification and testing in your environment is encouraged. This resource fetcher calls out to an API endpoint to get the desired resource.
The event 'ResourceFetcher-BeforeFetchFileContents' is emitted; it is expected that some code is listening to that event, and constructs an appropriate URL and body to be sent to the API, based on the filename, perhaps; in that method the config.url property should get the constructed url.
I would expect that the maintainers of the repo would edit this file further before making it public; fixing formatting, comments, and maybe revising the functionality a little bit.