Support pulling h5p libraries from alternative source

[develop-Greenant]

We are working on some modifications to H5P libraries and would like to have a simple mechanism for publishing those libraries for testing.

I note the discussions in #1305 regarding the dev-mode and also #1159 which allows the loading of libraries from local files.

These are helpful but this feature request is slightly different.

Would it be possible to load libraries from a specific URL? I am not sure how the "H5P Libraries" finds the available libraries currently, but it would be great to have an option to populate the list with custom libraries.

For instance, this could scan: https://example.net/my-h5p-libs/ and treat each subdir as a library folder or use some sort of manifest file to give the list of available libraries for download.

This setting could then be made by the user of Lumi if they have a source of additional libraries available. For development, this would allow easy publishing of libraries to a URL for extension of the current library list.

[sr258]

I like this idea! This would enable custom content type repositories, much like there are custom repos for apt-get in the Linux world. It will require some work in the underlying h5p-nodejs-library, but it's certainly doable. The H5P Content Type Hub already works a lot like you've described: there's an index file with metadata in JSON and some .h5p files that the system simply downloads via HTTP. It should be relatively easy to add additional sources that are merged into a final list.

You do know that you can simply package your library into .h5p files and open them in Lumi to test them even if they are not in the list from the H5P content type hub?

[develop-Greenant]

@sr258 glad you like the idea. Yes, we're aware of being able to load in .h5p files which is also a good interim solution.

We're happy to start work on this feature, could you point us to where in the code the index file is loaded?

[sr258]

It's great that you want to contribute to the project!

As Lumi is basically a client-server application there are two entry points:

• the server entry point can be found at server/src/main.ts
• the effective client entry point can be found at client/src/boot/index.tsx. The client uses Redux for state management, which can be pretty complex and verbose. I'd recommend you read up on Redux if you don't know it yet.

But Lumi is only the GUI, everything that's truly H5P-related is managed in dedicated packages in the h5p-nodejs-library monorepo and this is where it makes most sense to start off developing. In this case you'll want to look at the ContentTypeInformationRepository and ContentTypeCache. To add the capability to use other repos, I think there's need for a second type of ContentTypeCache that handles unofficial ones (I wouldn't use the current ContentTypeCache for this, as it also registers at the source, which is unnecessary for a custom source, but simply how the official H5P content type hub requires it). The ContentTypeInformationRepository must be extended to manage multiple sources by having multiple ContentTypeCaches in operation. The IH5PConfig object must also be extended to allow dynamic configuration of the sources.

[develop-Greenant]

@sr258 thanks for the details, we will look into those references and see what we can do to integrate - will report back on this issue once we have a test branch working.

[aswinm]

Hi team,

I've started working on this issue and I went through the relevant source of both Lumi and h5p-nodejs-library. I went through the ContentTypeCache file and I am assuming we will have to create a similar component for the list of jsons, and also update the getLibraries function to pull the libraries from the json files too. I am a bit confused about where this data is stored and should I be creating models / db handling for all this.. Could you please point me how that section works for the existing libraries?

[sr258]

The ContentTypeCache fetches the JSON data from Joubel's official HTTP endpoint, converts the data into an internal format and then stores it in a key value storage that is passed to it when it is constructed. The key value storage might be a simple file storage (src/implementation/fs/JSONStorage.ts; used in Lumi) or could be something like a Redis cache for distributed systems (if you scale the server horizontally with multiple instances).

The best way may be to start off by simply modifying the existing ContentTypeCache until your source works. Once this is done, you can think about adding dual-source functionality and configuration (e.g. by extracting an interface IContentTypeCache from the class and adding a third class that can manage other ContentTypeCaches and merges its data).

You don't really need to create models I thank as the classes won't do much more than read some JSON data and save it in storage. Introducing model classes would probably be overkill. DB handling is also not necessary, unless you want to read the content type information from it. Storage is done by calling this.storage.save().