2

(I have a problem with Google Chrome improvements that will drop support for my current solutions.)

I work on project where I move desktop system to an Intranet web application.

The crucial requirements are:

  • to move desktop system to a web application
  • to reproduce every single functionality from the desktop system in the webapp

While 95% of work requires creating casual web application, there is one thing which is non-standard to handle: my application must perform some actions on the client computer. These includes:

  • connecting with libraries
  • launching desktop apps
  • file manipulation in background

The example scenario is to integrate my system with some machine in the lab. I have to integrate my web application with drivers on client computer via DLL (desktop app did this, so my app have to do this as well).

Theoretically scenarios of the desktop actions may vary and I just want to implement some interface that will handle all the "client-machine" job the desktop app has done, so there is no need to work on every single scenario (but of course every scenario should be tested).

My solution was Java Applet. It worked. But then Google Chrome decided to drop support for NPAPI plugins, so in September'15 Java plugin (and my applet) won't be supported (http://blog.chromium.org/2014/11/the-final-countdown-for-npapi.html).

So my another solution is Java Web Start. It works. But now Google Chrome decided to drop support for background operations of external protocols (https://code.google.com/p/chromium/issues/detail?id=348640), so from Google Chrome 45 my Java Web Start solution won't be supported.

(Both above solutions work on Firefox and IE.)

The question: What other technology can I use to interact with a client machine from my web app?

Other remarks:

  • I am reluctunt to write my own PPAPI plugin or Chrome Extension - I prefer one solution working on all major browsers.
  • I know that StackOverflow community does not like discussions about technologies, so please focus on describing possible solution to my problem.
Bru
  • 514
  • 3
  • 14
  • The bug you linked to is about changing the behavior of launching other apps *from iframes* via custom schemes, *on iOS*. It has absolutely nothing to do with the question you are asking here, and nothing to do with Java Web Start. – smorgan Jul 09 '15 at 17:55
  • 1
    If you want to do things that explicitly violate the sandbox model of the web platform, then a requirement that the solution be identical in every browser is probably not reasonable; the only thing likely to be supported across all browsers is the web platform. It's probably worth taking a step back and asking yourself why, if what you want is to be able to do arbitrary interaction with the OS, you are replacing a desktop application (which supports that model) with a web application (which does not). – smorgan Jul 09 '15 at 18:03

1 Answers1

0

We struggled with a similar problem as we need to connect/access electronic devices over JNI->DLL. The only technology where this is currently possible are applets. Period. (And even that is tricky since certain combinations of browsers/java versions/operating systems do not work or have problems, but this is another story...)

There are web technologies like HTLM5, JScript which can replace some functionalities of applets however in certain scenarios (like yours) there is no current alternative available - and you named some of those:

  • connecting with libraries like *.dll, *.so etc.
  • file manipulations
  • launching applications

And doing that across browsers and operating systems!

Solutions?

  1. Tell your users that certain browsers can't be used (like Chrome and Opera Next)
  2. Write individual plugins for each browser (which probably is beyond your budget ;-)
  3. Did you consider writing standalone application(s) in form of an executable file? The user must download and run it however e.g. java or plugins also need to be installed. But then there is the security aspect of that (downloading an and executing an executable file) - certainly not an easy decision
  4. Have a look at FireBreath 2 - (just read about it in some posts, however didn't try it)

  5. There are lots of discussions on SO to this topic so take a read:

Community
  • 1
  • 1
Lonzak
  • 9,334
  • 5
  • 57
  • 88
  • It's not clear what you mean by "the security aspect of that". An application that has the power to link to arbitrary libraries, launch arbitrary apps, and alter arbitrary files, is not somehow less secure when run as a desktop application than as a plugin. – smorgan Jul 10 '15 at 16:05
  • I meant that allowing and telling the user to download and start an executable (also) involves a (security) risk. Wasn't meant to compare the level of security between the both... – Lonzak Jul 15 '15 at 07:07
  • It seems odd to flag just your option 3 as being a security risk, when by definition anything with the capabilities listed in the question is a security risk. – smorgan Jul 15 '15 at 22:56