Thanks , I agree it is a faint idea, but at least it would free the core-api and core-gui stack from Java6 and can make the project fly. That was also our initial idea. Of course the start of the .bat would not always required for the end-user.

If you have any idea on how to start you are welcome, I can create openhospital-cli repository on GitHub and start to have some tests over there, what do you think?

PS: I have still to review (well) OP-159, my aim is to do it after next release 1.10 that is on the way

Hi

Thanks for reviving this issue . Actually I did give a few thoughts about it in between time. We cannot be sure if we want to add it to SPA or not until and unless we know the exact hardware used. I do not have experience of working with such devices. But another option that I see which could be potent is that we can extract out the native lib and hardware devices code from gui to cli and then cli will execute such native code and send the data captured using these devices to api using http / message queues. So any scanned data or images will still be displayed on the new ui via api instead of gui but the user might have to run a .bat file. And then we can eventually start supporting devices in SPA once we find our their compatibility or support on browser and remove them from cli.

This is a very initial thought and a faint idea rather then a well developed approach.

Hi , did you have any clue on this? Shall we try the “path” of adding hardware support to the SPA or to create a third component like the aim of this issue?

We are moving to SPA because the actual gui is core-dependent and force us to install the application on all clients; at the moment the client-server nature is given only by the JDBC connections (the server is the DB). With the API + UI project using the CORE as library, we can gradually move to a web-like application where we should be able to deliver only the server part and the client will use only the browser.

At the moment we have not much, the idea is for future needs. We have been testing label printers:

• Zebra LP 2824 Plus

• Zebra GX 420D

GSM modules:

• any phone or GSM device, USB connected

Fingerprint devices:

• DigitalPersona 4000B

USB Webcam:

• No specifications (most work)

Future uses:

• USB Webcam (I think these are handled enough by any browser)

• Barcode readers (they are mostly seen as keyboard/input device)

• Fingerprint devices

• POS devices

• Label printers

• Card/Bedge readers

• Other medical equipment-machinery connected to the client

I’m not a front-end developer but I think the aim of this issue is to free up the CORE component from all these hardware-related problems and think about a CORE+GUI+CLI (without API and UI)

Hi .

That is right. Having native access from browser can be challenging. So let me try to understand more by getting more context from you. a) Why are we moving to SPA in the first place if we have dependency on native hardware components. b) Do we have list of hardware devices that our system uses

Due to advent of Node a lot of hardware support should have been added in JavaScript (that is my assumption). If we have a list of devices that we want to support we can check their library compatibility in JavaScript and then we can have better understanding of how browser ready we are.

P.S - May be you have already done this exercise. I am just trying to gain the context for my better understanding.

Thanks.