-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What are the "interfaces" for Readium-2? #14
Comments
It depends what you mean by interface, but IMO there's already something similar to the Readium-1 division being discussed:
Which means that we could have at least the following interfaces:
|
As a follow-up to our call and my previous comment: I think the HTTP server itself and the EPUB parser is a big building block here. It can be:
Different modules can then plug into this building block. Let's take search for example:
I should be able to potentially replace the search module (for example use something Lucene based instead of a basic search), without any impact on what I've described above. This provides a first idea of what the API and requirements could be for a number of modules. This includes:
Other modules will either be entirely native or written in JS, this includes: pagination, user settings (style, night mode), notes/highlights/bookmarks, text to speech and media overlay support. |
For modules that won't be handled in HTTP through the manifest document, we could do the following:
For JS, I'm sure that other people who are more experts than I am could chime in cc @fchasen @danielweck @jccr |
There is much "agreement" that Readium-2 should have well-defined interfaces (APIs). What are those interfaces to? From? This clearly comes back to what is the overall architecture of Readium-2?
What language are they written in? JavaScript? TypeScript? IDL?
The text was updated successfully, but these errors were encountered: