Proposing OPDS feeds to users, ready to add to "Catalogs"

[kevinmainairungu]

We see how the OPDS feed is stored after the user inputs the feed, but do not see a good way to add a fixed feed. Would this affect how the opds model is implemented? My thoughts were this would probably lead to a lot of instances being restructured. Would this be a constraint? Could we discuss a recommended implementation? Happy to take if forward, but would appreciate your thoughts on a solution.

[llemeurfr]

Good question, as in many situations, an app based on Readium Desktop will at least list some possible OPDS feeds that the user could configure himself. And in some apps, pre-configured OPDS feeds will be offered.
We should first discuss here the required changes in the software architecture, enabling these 2 use cases.

[kevinmainairungu]

@llemeurfr thank you. Talk soon

[danielweck]

A couple thoughts:

• Using the new CLI API, in principle Thorium / readium-desktop installations can be provisioned with pre-defined OPDS feed URLs via a post-install script (e.g. as part of a NSIS installer for Windows, for example).
• We can also hard-code a curated selection of OPDS feeds into the application, so that users do not have to manually enter URLs (e.g. Feedbooks, but there are many more candidates, for example https://github.com/readium/r2-streamer-js/blob/develop/docs/opds.md#a-selection-of-public-opds-feeds )

[llemeurfr]

@kevinmainairungu the first solution proposed by Daniel seems the most flexible, as it can be tailored to different use cases, still using the same application. What is your opinion on that?

[kevinmainairungu]

@llemeurfr I agree. This can be fully modular and can be re-used in different cases with the same application. A post-install script will be much easier than having to hard-code the feed every time.

[llemeurfr]

Do you think you could develop this feature with our help? If yes what do you need?

[danielweck]

Related issue: #608

[panaC]

may i close this issue ?

[danielweck]

I am in favour of closing this issue, as well as this one: #608
I do not think that we have a consensus to promote a particular set of OPDS feeds directly from within Thorium. Adding OPDS feeds via the UI is easy enough. If vendors need to automatically include a list of feeds in their builds, they can easily do this in their fork, no need to add the overhead of an additional API in Thorium to do this. Just my two cents :)

[llemeurfr]

Not so quick. We'll soon be able to propose an open set of libraries with OPDS feeds, from which a user can choose one or more. This will soon be openly available via De Marque.

[llemeurfr]

The technical solution must be made so that the eKitabu build can exchange Thorium bootstrap structure with its own.
I'm thinking about a GET on a specific URL (configurable for each build) which fetches a specific json structure containing a list of OPDS feeds.

[danielweck]

Ah ok. Good to know :)

[kevinmainairungu]

The technical solution must be made so that the eKitabu build can exchange Thorium bootstrap structure with its own.
I'm thinking about a GET on a specific URL (configurable for each build) which fetches a specific json structure containing a list of OPDS feeds.

@llemeurfr I agree with your statement. @danielweck I'll lias with the team on the status on this issue and get back to you.

[danielweck]

Related issue: #1336

[llemeurfr]

To better scope this issue, a good use case is a school or a company which wants to deploy Thorium on a large set of PCs. When installed, each Thorium instance should display an initial set of OPDS feeds. The list of feeds could be online and processed in a post-install script. Its format should be of this form -> http://libraries.aldiko.com/home.json.

See also opds-community/drafts#38 (comment): the exact spec is missing.

[llemeurfr]

As per team discussion today, proposed solution:

• let a user install Thorium (or fork of) in the usual way.
• let the user setup a specific environment variable (readium-desktop-init?) which value is either a URL or a file path (useful for getting info from a Content Access Point).
• Launch Thorium.
• Thorium will test the presence of the environment variable. If found, will fetch content from the value, will parse it.
• This content is a JSON document which contains init instructions, with a version number.
• If instructions with this version number were not applied earlier, will follow the instructions.
• Instructions can be to init some OPDS feeds (we may adopt the structure described in the previous comment). Other instructions may be created later (e.g. import some EPUB files in the library).

[danielweck]

Related issue: #1336