Yes i think this is the best approach. The administrator should definitely be aware of the difference.
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.
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.
Yes, I broadly agree with @burke.
In my opinion the most important user of the store is the administrator of a production OpenMRS installation, and for that user persona it’s more important to get the right thing, than it is to do a one-click download.
So, I believe the store UI should work basically as it does now, that when you pick a module/extension, you see all available versions (should also show info about requirements to run those versions).
Being able to install directly from the store is a nice-to-have, more valuable to developers than to real implementers, in my opinion.
I have shared a draft proposal with OpenMRS. I will appreciate your feedback
The deadline is fast approaching and i have not had any feedback on my proposal yet. @r0bby i know you already made it clear that you review proposals only for your project, but it will be an honour to get feedbacks from you. . I have already ping @pascal and he says he will look at it, but will appreciate feedbacks from anyone available.
I will look at it later today
@pascal thanks for finding the time to review my proposal, but it seems my proposal was a little long, given your comment on my proposal and @r0bby’s on this thread Tips for a successful proposal, 17 pages might have been a little too much. I have done some changes which involves @r0bby’s tips which says, proposals should lead with the template questions, so i moved the answers to those questions right after my abstract as he suggested. Also i tried deleting some details to reduce the number of pages but i could only lay off 1 page. Everything i have so far in my proposal seems very important. And most of the spaces is due to the mockup. @pascal @sunbiz, @r0bby i would be very happy if you could find some time in your busy schedule to look at it’s current state and provide some feedbacks .
And @pascal if you think i have deleted some relevant information, because you told me not to worry about the length, that is not a problem, i used git to manage different versions of proposal, so a simple git reset will bring back everything in my last commit.
17 pages is a bit much – but if it’s largely wireframes – I’d say top out your proposal at 10-12 MAX – I’d say leave it alone unless one of the mentors for your project asks – like i said, not hard and fast.
@r0bby @pascal actually said i should not worry about it. But if you look at it, removing anything will make the idea am conveying not very clear. Just answering the questions asked on the wiki took me 4 pages, so my implentation takes at most 5 pages.
Hi @sunbiz On this talk post most of the developers have agreed to use bintray.com for distributing OWA’s and we are already testing it. I have a few questions 1.Instead of developing modules.openmrs.org, are we going to use Bintray in our project? 2.If we are going to use it,what are our updated project objectives?
Thanks, Vishnu Rao
Hi @vishnurao, Congrats.
My proposal on this would be that, you should still enhance modules.openmrs.org to handle uploading of owas and modules from the UI. But at the backend, you will actually use the bintray rest api to host copies of all the packages on bintray. So that a community member who is not yet familiar with bintray will still have access of all apps and modules from the Modules repository even though they are hosted on bintray. And also apps uploaded from bintray should also be displayed on the modules repo(still with the help of bintray rest api). Good luck.
We can still use modulus to pull metadata – but store the actual binaries on bintray
I’d say store everything on bintray inc. metadata and use the REST client to display all on modules.openmrs.org.
You can easily store custom metadata (supported OpenMRS versions, required modules, etc.) in bintray using attributes https://bintray.com/docs/api/#_get_attributes
Modulus seems like a failed experiment. Nobody in the community seems to want to support it and fix bugs. Let’s use bintray from now-on.
I suggest you consider this approach (as an extension to @raff’s comment):
- build a completely new application from scratch (using a very-popular-today JS framework)
- this is a very thin layer on top of bintray
- no data storage at all for the OWAs, outsource this completely to bintray
- this indexes the OWAs on bintray, and presents a few valuable summaries in an openmrs.org-themed UI
- eventually this should support indexing OWAs across different organizations, e.g. OpenMRS, Bahmni, PIH, Sunbiz, etc.
- show things like most-downloaded, top-rated, most-recently-updated, etc
- could have a data store for features like “OWA of the month” or “included in Reference Application”
- all non-trivial functionality (e.g. giving a rating, downloading an old version) is just a link to bintray
- The scope of this GSoC project is just to build our “OWA App Store” but be aware that this should eventually replace Modulus for our OMOD files also.
FYI this GSoC project is perfect for modifying Modulus UI to bintray.com . I agree with everything @darius said. HOWEVER, I don’t think starting from scratch is a good idea – let’s use what’s there and what works and refactor it to work with bintray.com.
I brought this up as a larger discussion here:
If we don’t do it now – it will never get done.
Please continue discussion in #dev or request a new category