is OpenMRS CLI a good project idea ?

Hello all,

I could not participate earlier in the developers forum, as I came late :smiley: but I had this idea that I wanted to share: having a CLI interface in addition to the Web interface can be helpful for quick access/entry of data. is this a good project idea ? what do you think, is it feasible ?

Could you clarify a bit more how you envision that CLI data entry would work?

I guess it could be done with a command that reads either from input or from a file ( for several entries), e.g add concept [required fields] [optional fields] . I have not though about the format yet

That seems like the REST api can do everything…why would anyone use it like that?

I agree that I don’t see a use case for a real user wanting to interact with OpenMRS at the command line. Our end user is a doctor, or a data clerk, not a sysadmin.

But keep brainstorming!

I could see some utility for a CLI, especially if it was incorporated into the SDK.

> sql select count(*) from patient
1320

> get visits.enabled
true

> patient.getPatient(1).personName
John Doe

> restart
Restarting OpenMRS... restarted in 27 seconds.

It’s harder to imagine a CLI like this being useful for data entry.

I actually see some utility in this too: CLIs are inherently faster, smaller, and, to some, easier to use - even for data entry.

> create new patient

 First Name: Bob
 Last Name: Jones
 Age / Birthday: 12/3/1877
 ...

 Is this correct? y

 Created user, id=42

It could require far fewer resources to run and fewer bits to download. Is it worth the investment? Dunno.

exactly, @parkererway you said it. Some people prefer CLI especially for repetitive tasks. It could also have some utility for bulk data entry.

@darius Remember back in the old days everything was done through CLIs :slightly_smiling: I think if it simple enough, a doctor can manage to use it.

search, configuration, and monitoring can also be other use cases for the CLI. something like:

show patients with age > 20 and ...and ...

config formentry enabledashboard true

I think it is worth giving it some thoughts in the future.

It could also be useful for managing modules and openmrs versions:

install module rest

install modules reference-application

update module atlas version 2.0

update openmrs version 1.9

Seems cool, what do you see this being written in? Java (even CLI) is a memory-hog.

C language is a good option, with the help syscalls, you can do pretty much everything. Python is another alternative.

1 Like

Python would offer a wider base of free & open source software contributors. We definitely get people coming to OpenMRS looking for python projects much more frequently than we do C* developers.

3 Likes

How about Node JS ?

If you were to embed the CLI tool into the SDK, then Groovy would be an option.

1 Like

I’m not sure why I stopped playing with Groovy, but it’s a beautiful language. Node.js, Ruby, Python are all options. I would object to C, too much care needs to be taken with C.

A post was split to a new topic: Proposing an unlisted GSoC project idea

I think the question i have is, is there any implementation asking for this?. The other thing is that in production we recommend admins to add/remove modules to/from the modules folder and restart OpenMRS as opposed to starting/stopping them through the application, so i wouldn’t put much effort in the starting/stopping modules feature.