My name is Ivange Larry Ndumbe and am a 3rd year computer engineering student and a community member for some months now. I would like to work on this project. The project objective says we should extend the modulus api to be able to able to upload OWA. But i was thinking, it would be nice if we could have this a separate project from modulus with its own api and UI(I mean a more storelike UI) also with an access url like store.openmrs.org.
2 Likes
I think it would be good if it were in the same place because then we can leverage the work that has been done on modulus, like the OAuth connection, backend infrastructure for installation through OpenMRS module management UI etc. You can give the appstore like UI for the OWA, but I think we should use the modulus infrastructure.
3 Likes
I agree with this.
1 Like
Makes sense. Thanks for the quick response. I will get started with my proposal. 
2 Likes
Iâm currently a blockerâŠmodulus requires ID dashboard currentlyâŠworking on getting that working
2 Likes
Ok will be waiting then. Please donât forget to ping me when its done.
1 Like
Itâs not broken, itâs just not the easiest to setup â itâs documented â but we just wanna make it as easy as possible.
1 Like
I have been working on some mockups and i would like to get you feedback on them.
I am still documenting my use cases but i would like to get your feedback on these ones for now and also would like to know if you had a few non obvious in mind especially for the admin section. These are just for the changes on modulus frontend, that for OWA module will be a little different. Also i noticed that for modules we keep all versions of module and the user chooses which to download. But on conventional app stores, only the latest update is available for installation. So what do you think would be best(keep all app versions or just the latest version).
1 Like
Given that we have modules, web application apps, and OWA apps in our ecosystem, it would be nice to try to consider how we can manage these in a way that is simplest (and least confusing) for users and developers.
- Modules â traditional OpenMRS modules
- Applications âappsâ â the âappsâ we see in the Reference Application home page and the âappsâ showing up in various Angular-based distributions of OpenMRS
- Open Web Apps â apps that follow the OWA spec and are installed via the OWA manager
There are definitely going to be cases where people will just want to browse one of these types (e.g., in the OWA manager, you only want to show OWA apps); however, I can imagine there will be other cases where people may want to look at all the things offered across types (e.g., âall extensions that have to do with diabetesâ or âall extensions rated highestâ).
So, creating an app store is all good, but itâd be nice if we supported (or were prepared to support) the ability for someone to browse all types of extensions through a single UI â i.e., create a unified UI that can easily filter to a specific type (and maybe even do that by default) but avoids creating a separate UI for each type. For example, if we add user rating capabilities for modules, itâd be nice not to have to repeat the same work for apps and OWA apps or have them behave differently.
Lastly, can we come up with some friendly terminology than âOWAâ for users? Or is teaching people the distinction between âweb applicationâ apps and âOWAâ apps enough? Or is there a way we can prevent users from having to care about this distinction? My instinct would be to distinguish between âweb appsâ and âappsâ (i.e., âappsâ are the things you add to your web applicationâs dashboard and âweb appsâ are almost like little standalone web applications themselves that may offer similar functionality but follow the OWA standard.
Anyway, I mainly just want to make sure we donât end up (1) confusing users and (2) creating unnecessary distinctions between various types of extensions in modulus that we arenât able (even if its done later) to show them in a unified interface.
-Burke 
1 Like
@burke, this may be a distraction from the GSoC project focus of this thread, but I should point out that what youâre calling âApplication âappsââ are not something that exist in downloadable form, they are merely a UI approach that we used to build the reference application.
Specifically, anything that attaches to the extension point org.openmrs.referenceapplication.homepageLink is displayed on the home screen. A module could provide zero, one, or many of these. Also, an administrator can add these things through an administrative UI.
Thereâs an ongoing discussion here between Saptarshi and I about letting OWAs add these âhomepage appsâ too. And like a module, an OWA could conceivably add 0, 1, or many homepage apps. (The spec has a single start_url, but thereâs nothing to prevent multiple homepage apps from having deep links into an OWA.)
Anyway:
- I agree we should have one unified âstoreâ for modules and OWAs
- by default Iâd assume this should start from the current modulus UI
- we do need users to know that homepage apps are not the same thing as OWAs.
I noticed that writing the same code for modules and OWA is not a very good idea. I agree we should definitely have a unified UI, this will not only make life easy for users but also for developers. Just so we are on the same page, you are suggesting that we should not have different UI pages for the same functionality twice, like for example instead of creating separate forms to upload module or OWA, we should just have on upload form that is able to upload either an OWA or a module. And also users browsing the store should see all available extensions(OWA or module) from the same UI, but maybe in the description page of a particular extension we mention what type of extension it is since they have different ways of been installed. So the approach will be redesign modulus-ui to provide a unified interface for OWA and modules but the owa manager running in openmrs webapp should only provide a ui for OWAs. I guess we need a generic name then that will group together OWA and modules.
Creating a distinction between OWA and homepage apps. @burke I agree this might be a little confusing to users and it is very important for us to make users understand the difference, but is the distinction between the two a responsibility of the store? I mean the store should just take care of hosting extensions, whether OpenMRS module or OWA. Also since homepage apps have a different workflow, putting it in a unified interface together with modules and OWA does not sound like a good idea to me. Will a wiki be enough for this or you had something else in mind about how to make users understand the difference. @sunbiz, @pascal i would love to hear your thoughts on this.
1 Like
I am saying that the user should experience a single âstoreâ from which they can access all OpenMRS extensions (modules and OWAs), and since we already have a âmodules.openmrs.orgâ, this store should be the next version of that. In the same way that Chrome Web Store has both Apps and Extensions.
I guess I probably agree with the specifics you have said, but I havenât thought it through.
I think the store only needs to know about Modules and OWAs. (The documentation of a Module or OWA should eventually state how it will appear in the reference application, and thatâs all that the âapplication appâ or âhomepage appâ is.)
3 Likes
Iâm probably showing my ignorance here, but do we really want consumers to have to distinguish between modules and âowasâ? Arenât they more or less functionally equivalent to the end-user? If we were to build a âconcept managementâ owa that adds a new app to the homepage that is backed by one or more pages with one or more functions, how is this different to an end user from us providing a âconcept managementâ module that provides the exact same thing?
Mike
2 Likes
Probably different in the way they are managed within an openmrs instance, am not yet very much into the OWA openmrs stuff though and just thinking 
I agree, that they are functionally equivalent but they have different ways of been managed(installed, uninstalled, updated). But i think we can still hide these details from the end user. That is if the store only allows owa or module installation directly into a running openmrs instance, as it is done by other appstores, it will be possible to hide this underlying difference of how they are installed. But when the store supports downloading of apps and modules which can be manualy installed by an admin, it would be difficult to hide the difference between OWAs and modules since the installation process for OWA and modules are different. Still, even if the we are able to hide the details of installation, an admin will still need to be aware of the fact that these are managed differently since modules are managed from the manage modules page legacyui, while OWAs are managed from OWA module. To hide this detail too, i think we will need to add something like a manage extensions page inside core that will handle the management of OWA and modules with a uniform interface, in such a way that an end user may never know that there is actually a difference between the extensions.
cc @darius @burke @pascal @sunbiz, i would like to hear your thoughts on this.
1 Like
The end-user doesnât care whether something is an OWA or a Module. But the system administrator who is managing an OpenMRS system should care, and should know that they are different.
An OWA is lightweight and costs nothing to deploy (but is more likely to require the admin to have to do manual configuration to attach it to the reference application UI).
A module is heavyweight and expensive to deploy, and it also has more (potential) security implications.
1 Like
Yes i think this is the best approach. The administrator should definitely be aware of the difference.
1 Like
My primary concern at this stage is that we avoid creating complete distinct & competing mechanisms for handling these different types of extensions in modulus. Instead, letâs enhance modulus to understand that there are more than one type of OpenMRS extension. Not everything will be a module. Starting now, some things will be OWA apps. In the future, we will likely add a new type of extension (i.e., our vertical packages that include a mix of modules+apps+content).
So, to get more specific⊠assuming we use the term âextensionsâ for the all-inclusive name for these things, Iâm proposing something like:
- Consider adding extensions.openmrs.org as an alias for modules.openmrs.org that we will begin transitioning toward being the default.
- Add âextension typeâ as a property of entries in modulus (e.g., âmoduleâ or âowaâ for now, will likely have new ones in the future)
- Start migrating the modulus API from âmodulesâ to âextensionsâ. This could begin by adding OWA capabilities through new âextensionâ endpoints that include both OWA & modules in responses.
Clients that want to filter to specific type(s) of extensions should be able to do so easily by specifying the extension type(s) in their API requests. So, for example, an OWA manager could show an embedded âOWA app storeâ backed by modulus via only asking modulus for âowaâ extension types; the module manager could be refactored to do the same except limiting its view to âmoduleâ types. Users visiting modulus could have a UI that shows both in a unified interface.
An important outcome of this approach is that, when we add user ratings and other features, we donât have to repeat the work for each type of extensions independently; rather, we add these features with the understanding that there are different types of extensions and all extension types benefit from the new features.
3 Likes
Hi @burke
I had something like that in mind even though it was not well polished like you just did. If you look are the screenshots i shared you will notice, that i did not create a different UI for OWA, I just extended modulus, but i guess they were not clear enough and my idea was not exactly like yours. Because with my idea, i had to add new html partials for OWAs and replicate most of the grails services and controllers to work with OWA, now i see that will create the problem you suggested that when changes are made, they will have to be replicated for both OWA and modulus. I think your approach will be the best and i would like to know @darius, @pascal and @sunbiz thoughts about it.
Also i wanted to find out what you all think about version management in the store. I mean with modules, you have the option of downloading what ever version of the module is available, but with appstores, as you click on the install button on an app, it installs the latest version of the app available. This can be done from OWA manager since that is the only place where we can install an app directly into a running instance of openmrs. But from extensions.openmrs.org(an alias for modules.openmrs.org as suggested by @burke ), since we cannot be sure if the person browsing there is having a running instance of openmrs, we can only provide him with a download option, so my questions is should i maintain the convention for modules where when you click on an app it shows you all the available versions to download from or should it just display the lastest version of the app as it is done with most app stores.