It’s time to kill off the current modules.openmrs.org, because (a) the codebase is unwieldy and we haven’t been able to support it, and (b) we want to evolve to more distributed model where not everything has to belong to and be hosted by OpenMRS.
I propose the following:
- We build a very thin application that functions as an index of OpenMRS modules
- We do not store or host modules ourselves
- Support indexing modules from a few (pluggable) providers, e.g. mavenrepo.openmrs.org, bintray, and github releases.
- We should also support OWAs (and storage on npm) and other types of things
- The functions we need to support are:
- as a user I want to browse/search the index
- as a user I want to download a module version
- as an author I want to add my module (that I have published via maven, bintray, or github) to the index
- as an admin I want to approve/remove a module from the index
- Probably also:
- support for installing a module from the OpenMRS legacy UI manage modules page
- tagging modules (e.g. “in Refapp 2.5”) and letting users browse by tag
- display compatibility of module versions with openmrs-core versions and/or search based on this
I’ve been thinking about the simplest possible way to do this (e.g. “serverless” and don’t have to mess with auth schemes or OpenMRS ID integration):
- the database of modules to index is just a google sheet
- authors can submit their modules via a google form that adds to that sheet
- admins approve a module (or mark it as spam) by setting a field in the sheet
- server component using spring-boot (to leverage OpenMRS community’s Java/Spring experience)
- this watches the google sheet, and regularly checks for updates on any of the modules we’re watching, and indexes them
- “index” can be in-memory, or stored ephemerally with no need to back it up, since it can be regenerated at any point (long-term data is in the google sheet)
- exposes a simple private REST API to the web client
- web client component is a simple JS+REST single-page application
- provides read-only access so there’s no need to implement auth
What do people think about this?
PS- It’s also worth looking at the OWA App Store project from GSoC: wiki page, talk post, blog post. That project takes a similar approach, but specifically uses bintray, and assumes everything is stored in one (OpenMRS) bintray account.
Do people think my idea of “distributed publishing” (i.e. modules are primarily published to a host of the author’s choice, using bintray/github/maven’s standard tooling) has value? Or would it make more sense to just make some incremental changes to this GSoC project?