10

We run a cloud-based medical software, and a very important part of the program is bridging to an imaging software straight from our website, passing information through command line arguments. We pass a patient's name and ID through a Java applet, and it will open the imaging program that is installed locally on the user's computer. There are many different imaging software vendors that we bridge to, so it isn't possible to make our own imaging software in the browser.

I was wondering what the best way is to pass in these arguments and open the program, without using the Java applet that we have. As you all may know, Google is dropping NPAPI support in Chrome, and has just recently pushed update 42 which disables Java applets by default. It is still possible to use them for now, but support will be dropped completely by September. So, what would be the best thing to replace our Java applet with?

3

3 Answers 3

13

Running local programs through the web browser is frowned up for most scenarios, so browsers don't really want to implement that support.

One idea I had that you could do, is create some obscure file extension, and register your client-side app to open them. Then, your web page serves up some file, in that file extension. The file would get opened by your client-side app and the file contents would tell your app what to do. Then, configure the browser to download and open those files without confirmation.

5
  • 11
    Another solution is to create your own scheme, and have your application handle this scheme's links. So that for example, your application is opened when the foo://bar link is clicked. Commented May 1, 2015 at 20:56
  • Just to clarify - you're suggesting to create an application that the users have to download, then have a file downloaded each time we need to pass patient's info, and have that application open it? Then, that application would basically do what our Java applet does now and pass in the patient's name and ID? This certainly seems possible, albeit clunky. We are going for a lightweight implementation here, and we prefer to not have any client installs since we have users on various platforms, and it goes against the point of our cloud implementation. However, this may be the only solution here. Commented May 1, 2015 at 21:45
  • @RichardTyszka: package it with your desktop application. Clunky sure, but it could be made invisible to the user. Commented May 1, 2015 at 22:45
  • +1 It works. I have done it. In my case from the web me had to pass some data to a remote desktop app. We creates a file with the data, gave it a particular extension, then client-side associated that extension with our remote desktop app, so every time such a file is downloaded, the client machine opens the file with our app. Out app then reads the connection info from the file and stablishes the connection. Commented May 2, 2015 at 1:40
  • 1
    @RichardTyszka: You should first ask each of the image vendor you intend to support to see if they already have defined those "shortcut files" for their own applications. Then, instead of trying to come up with your own, you will simply create and send a shortcut file belonging to the version of vendor software that you know the user is using (and already configured with). Therefore, you do not need to create a Windows application just to dispatch to the third-party software.
    – rwong
    Commented May 2, 2015 at 8:17
1

"Java Web Start (also known as JavaWS, javaws or JAWS) is a framework developed by Sun Microsystems (now Oracle) that allows users to start application software for the Java Platform directly from the Internet using a web browser."

source : "http://en.wikipedia.org/wiki/Java_Web_Start"

With Java WS you can start desktop java applications (not applets).

You can use a JNLP link from Chrome : How to Configure Chrome to Open JNLP Files

And finally, this is how to pass parameters to your local desktop java application from the internet : Passing dynamically parameters to a Java Web Start App (JNLP)

P.S. : If your desktop application is not in Java, your can still use a Java desktop application as a relay to launch it.

5
  • This one is pretty similar, it would involve creating a desktop application and making the user download it on each computer they wanted to use imaging on. This certainly seems to work, and might be the only solution here. Wish there was a way to make this work without having to require the users to download anything from us, but our goal seems to be the exact opposite of what google wants anyone doing from a web site. Commented May 4, 2015 at 12:19
  • @RichardTyszka: It's the opposite of the goal of almost everyone. I do not want my browser able to launch arbitrary programs on my computer without very specific authorization. Think of the trouble that could be caused if visiting a web page could cause your browser to execute some arbitrary batch file some jokester left for you? Commented May 4, 2015 at 15:49
  • Yes you need some explicit actions from your users to allow this, for a security reason.
    – Tristan
    Commented May 5, 2015 at 6:45
  • 1
    For our plugin to work, we already have to add our site to a list on the Java security panel, have them un-block plugins on the site, and it also pops a confirmation message before using it the first time. I don't understand why this isn't enough security. Commented May 14, 2015 at 22:02
  • It's a bit long to copy/paste but it should answer : docs.oracle.com/javase/tutorial/deployment/applet/security.html I guess your applet is treated like a sandbox applet. "JavaScript code is treated like unsigned code. When a privileged applet is accessed from JavaScript code in an HTML page, the applet is executed within the security sandbox. This implies that the privileged applet essentially behaves likes a sandbox applet. "
    – Tristan
    Commented May 16, 2015 at 7:37
-2

Things that come to mind, but none as cross platform and browser neutral as Java is supposed to be:

  1. Create a Chrome extension.
  2. Convince Oracle to support Java in Chrome.
  3. Require users to use IE or Firefox.
  4. Have your "cloud-based medical software" people also support your imaging needs.

I'm trying to think of a clever, simple solution, but you're in a tough spot. I don't envy you trying to connect a browser-based app to a locally installed component. You're working against the grain big time.

1
  • 1
    Care to elaborate on number 4? We are the "cloud-based medical software" people. The imaging softwares are all created by separate companies; a few are web-based like us, but I know they use Silverlight which is also losing support in new Chrone, so they seem to be in the same boat as us. Commented May 1, 2015 at 21:37

Not the answer you're looking for? Browse other questions tagged or ask your own question.