Many changes, such as bug fixes, internal refactorings and documentation improvements, can be implemented and reviewed via the usual GitHub tools: issues and pull requests.
However, we ask that any change impacting the public API be put through a bit of design process and produce a consensus among the Readium community.
The REP (Readium Evolution Proposals) process is intended to provide a public space for discussing new features entering the Readium toolkit, so that all stakeholders can be confident about the direction the toolkit is following. It also serves as an archive and reference for existing (or soon to be) features.
This proposal introduces a dedicated API to easily figure out a file format.
Publication is independent of any particular format, knowing the format of a publication file is necessary to:
This API is not tied to
Publication, so it can be used as a general purpose tool to guess a file format, e.g. during HTTP requests or in the LCP library.
The goal of this proposal is to make the fetcher more flexible using a composite design pattern. We will introduce several
Fetcher implementations to answer different needs, such as resource transformation and caching.
We can make the Readium toolkit simpler and safer to use by exposing a single encapsulated
Publication, encompassing resources access and services.
Our goal is to improve extensibility and customizability of the
Publication type for reading apps. To achieve that, this proposal introduces two structured ways to extend a
Publication with additional features: helpers and services.
This proposal aims to specify the Streamer public API and showcase how a reading app might support additional formats. It ties together several concepts introduced in other proposals such as the Composite Fetcher API, Publication Encapsulation and the Publication Helpers & Services.
Offers a way to support more content protection technologies in Readium 2.
Being able to search through a publication’s content is a useful feature, often expected by end users. We can offer a unified API for the wide variety of publication formats supported by Readium to make it easy for reading apps to implement such feature.
Search can be implemented in many different ways, so being able to switch implementations without touching the UX layer would be valuable. For example, a reading app might want to use a full-text search database to improve search performance and search across multiple publications in the user bookshelf.
This proposal introduces a new Navigator API to draw decorations on top of publications, in a media type agnostic way. This new API is a building block for a variety of features which need to draw user interface elements (decorations) over a publication’s content, such as: