4 ms·

"GDS chooses what works..." Erm no. One GDS project requires end users to connect to a number of devices over USB from their Windows PCs. The logical choice is

"GDS chooses what works..." Erm no. One GDS project requires end users to connect to a number of devices over USB from their Windows PCs. The logical choice is to write a .NET app that does it. GDS chose to write the USB interop code in Java, wrap that up in a Windows Service, install a web server on the PC, write an HTML/CSS/JavaScript app that runs in the web server, which calls the Windows Service and talks to the USB device. That sort of thing (the above is not an isolated example) happens at GDS for a number of reasons - one is what the Register alluded to: they're good at webs sites, so they try to shoe-horn everything into the browser. Another is that they're despotically obsessive about "user need", so don't understand that user needs need to be balanced with business needs (reduce call centre costs), system needs (we've invested x in Windows, for better or worse), and operational needs (supporting a single, self-configuring .NET .exe on 2,000 desktops through WSUS is a lot cheaper and easier than installing, configuring and maintaining a Windows service, a web server and an HTML application on 2,000 desktops).

nailer 12y ago
Your post is not really much of of a response to my point about not using AJAX or CSS, but anyway: I image they'd rather not re-do a separate UI for a single platform. You can deploy a single MSI for a local web app just as easily as you can a .net app, and doing so isn't entirely uncommon.
7952 12y ago
A little off topic but I wonder if there could be a middle ground for this kind of app. Run the actual UI on a web server and give users a central URL to go to. Then have a service installed on the local machine that has an API exposed with CORS.
- Spearchucker 12y ago
  You certainly can. But when things go wrong you go from one to three places in which you have to look for the problem - the service, the network, and the server. Also, instead of a single package containing a single .exe you're now deploying to all desktops, and to a server. This in the context of developers finish the system, leave, and ops don't have the skills to fix a Ruby/node/whatever tech issue. While none of the options that work are technically wrong, it might be worth considering the differences between the best solution design, and a successful one.
- jasiek 12y ago
  ...or use Chrome's USB connector, if you must use USB.

nailer 12y ago

Your post is not really much of of a response to my point about not using AJAX or CSS, but anyway: I image they'd rather not re-do a separate UI for a single platform. You can deploy a single MSI for a local web app just as easily as you can a .net app, and doing so isn't entirely uncommon.

7952 12y ago

A little off topic but I wonder if there could be a middle ground for this kind of app. Run the actual UI on a web server and give users a central URL to go to. Then have a service installed on the local machine that has an API exposed with CORS.

Spearchucker 12y ago
You certainly can. But when things go wrong you go from one to three places in which you have to look for the problem - the service, the network, and the server. Also, instead of a single package containing a single .exe you're now deploying to all desktops, and to a server. This in the context of developers finish the system, leave, and ops don't have the skills to fix a Ruby/node/whatever tech issue. While none of the options that work are technically wrong, it might be worth considering the differences between the best solution design, and a successful one.
jasiek 12y ago
...or use Chrome's USB connector, if you must use USB.