New Repo Convention For Web Browsers Addons/Extensions

I think we should use the new convention for future support of web browsers addons and extension like “openmrs-addons-browser-addonname*” or “openmrs-extension-browser-*” .

Give your suggestion for this?

For. eg. I have a repo which is a googl chrome extension for an OpenMRS module, but doesn’t know what convention will be perfect?

I would imagine our existing openmrs-contrib-extensionname naming scheme would work well here.

However I did think of a few related questions:

What is the license for this code? Right now it seems to be a standard copyright to the author with no license. http://choosealicense.com

Presuming ownership is transferred to OpenMRS, what is the plan for future distribution of the Google Chrome extension? It currently seems to be published in the Chrome store under your name. We (OpenMRS) have distributed one application in the Google Play store but haven’t yet looked at the terms of the Chrome store. (Is it even necessary to distribute Chrome extensions via the store or can they just be downloaded and installed? Given the niche user base it may not be worth bothering with maintenance on their servers if we can just host it locally for download.)

Is there documentation and support information (including current names of the software’s owner/maintainer, such as provided in our modules directory) in the OpenMRS Wiki and/or will that information be clear in the software itself?

Thanks! :smile:

2 Likes

My suggestion for a naming convention is:

openmrs-contrib-(typeofthing)-(specificname)

So in this case it would be

openmrs-contrib-chromeextension-systemmetrics
3 Likes

Also, one more :slight_smile: I have been assuming the extension is actually compatible with Chromium (the larger open source project) and not just the proprietary Google Chrome browser - is that correct?

For reference, here’s a summary of our existing naming conventions (based on all repos under OpenMRS org):

Reserved names

  • openmrs-core
  • openmrs-standalone
  • openmrs-sdk

Categories

  • openmrs-module-*
  • openmrs-distro-*
  • Used for distrobutions of OpenMRS.
  • openmrs-contrib-*
  • Used for various types of contributions (tools, plugins, etc.).
  • openmrs-devops-*
  • Tools developed by the devops team.
  • openmrs-module-example-*
  • Modules specifically serving as examples.

Outliers

  • openmrs-maven-*
  • Only openmrs-maven-archetype-project. Probably should be openmrs-contrib-maven-archetype-project (or similar) to match others.
  • openmrs-example-*
  • Only openmrs-example-helloworldapp. Probably should be renamed to openmrs-refapp-example-* to match openmrs-module-example-* convention.
  • openmrs-test-*
  • First time I’ve seen these. Looks like repos created to test some aspect of module life cycle. Maybe we could get rid of them.

If we had a pattern of creating browser extensions for many projects, then openmrs-browser-* or openmrs-extension-* might be justified; however, since we only have one browser extension, I’d agree with @darius & @michael that we use the openmrs-contrib-* pattern for contributed browser extensions.

For the record, I’m with @darius:

I tested it on chrome browser only. I don’t know if it will be compatible with chromium or not :frowning:

As @burke suggested I used Mozilla Public License 2.0 :smile:

1 Like

thanks @pascal & @darius I used the same convention :smile:

It might be worth a quick test to make sure & document accordingly. (I wouldn’t guess that there are any problems with it.)