internetarchive
Simplify Trusted Book Providers integration
Proposal
A simplified Trusted Book Providers integration would mean that providers are added by adding the equivalent of json or yml entries to a registry, as opposed to manually adding new html files and classes for new providers.
There may be cases where a new mapper class is required between the ID / naming / url schemes of a provider and Open Library, however this should hopefully become the exception rather than the norm.
Justification
We have lots of trusted book providers pending evaluation and it would be great to arrive at a point where open librarians and contributing engineers can implement these solutions (and make it more trivial to review).
If done correctly, this could potentially result in dozens of new partner platforms that we can link out to, increasing access to tens of thousands of open access books.
Breakdown
Requirements Checklist
- [ ] #10470
- [ ] Dry up rendering of book provider
downloadoptions to only use one download options html - [ ] Add a new
provides: list[Acquisition]field to an identifier in openlibrary/plugins/openlibrary/config/edition/identifiers.yml , and construct aBookProviderclass from the identifier dict/yaml . This should use the@@@key like theurlfield to allow us to dynamically construct the acquisitions from the identifier.
Related files
Stakeholders
Instructions for Contributors
Please run these commands to ensure your repository is up to date before creating a new branch to work on this issue and each time after pushing code to Github, because the pre-commit bot may add commits to your PRs upstream.
I suppose that a yaml or json file is a good of adding new providers. We can also keep a field that asks if custom mappers are required (such as the render_download_options for the LibriVoxProvider class) which can either be filled with true or false.
Next, a script can parse through this file and add a new class and the default methods (the get_acquisitions and is_own_ocaid methods) under the new class. If the custom mappers field has been filled false, we move to the html files, else, the comment stating "Add custom methods here" is seen under the class along with the default methods.
Once that has been catered to as well, we move onto the automatic creation of html pages for the newly added provider. Currently, there is not a standard template that we're following for provider's html pages (correct me if I'm wrong). So that needs more thought and context to work upon. There's also the concern of either following a template for new providers from now on and/or making the existing provider's pages adhere to a template.
Overall this issue looks vital to me and will streamline the process to a great degree. Can I work on this?
Awesome, thank you @Spaarsh ! This one will need some breaking down. Let's start with DRYing the Read button first since it's a little simpler.
We currently have 7 read buttons in templates/book_providers.html
We also have a special more generic read button called direct_read_button.html in that directory. We want to migrate the other read buttons to use the same template/logic as direct_read_button.html. This will let us use the Acquisition class as an intermediary; the Acquisition class should contain all the information needed to render the read button.
The book provider sub-classes already have a get_acquisitions method, so you should be able to use that. As a first step, let's see if you can update standard_ebooks_read_button.html file to take in the same parameters as direct_read_button.html, and try to see what breaks/what information might be missing that we need to forward along as well.
Let me know if you hit any issues! I've broke this epic down into three separate steps, the above will be the first step of DRYing down the read buttons.
Here's the first subtask! https://github.com/internetarchive/openlibrary/issues/10470 . If you leave a comment on that one @Spaarsh I'll be able to assign you.