Shouldn't NI provide a way to serve a LabVIEW app on the web without the download runtime requirement for web clients?

[TedAnderson]

I think it would be to NI's benefit to allow a LabVIEW application to run on a web server, where clients would not first need to download a run-time module and restart their computer. 

We recently programmed a demonstration application for a client that wanted to host it on a web server for use by hundreds of its customers.  The "download run-time and restart" requirement squelched the deal, however, so we will not be developing the application any further in LabVIEW, if at all.  We don't really have the expertise in-house to develop in .NET or Java, so it is likely that another developer will get the contract.

Too bad, because NI would have been able to sell a good number of server simultaneous-access licenses.  And my company would have kept a sweet programming contract....

Ted Anderson

[LV_Pro]

NI's internet toolkit allows the use of other technologies that don't require the licenses or the RT download. It does require becoming familiar with both the toolkit and, as in the case of a project I'm finishing, CGI scripting. I too had an issue with the download requirement, as well as the licensing costs, as my customer is a not for profit children's science museum. They, and I, felt that a lot of their customers wouldn't want to have to download a multi-megabyte file and install it. Unfortunately many other languages (Visual Basic for one) require a runtime engine, but VB's is installed as part of Windows, giving them that advantage. Of course when you create an executible in LabVIEW it too requires the installation of the runtime engine, but at least there it can be part of the installation package.

Good luck,

[rolfk]

---

@Bairoa wrote:
I think it would be to NI's benefit to allow a LabVIEW application to run on a web server, where clients would not first need to download a run-time module and restart their computer. 

We recently programmed a demonstration application for a client that wanted to host it on a web server for use by hundreds of its customers.  The "download run-time and restart" requirement squelched the deal, however, so we will not be developing the application any further in LabVIEW, if at all.  We don't really have the expertise in-house to develop in .NET or Java, so it is likely that another developer will get the contract.

Too bad, because NI would have been able to sell a good number of server simultaneous-access licenses.  And my company would have kept a sweet programming contract....

Ted Anderson

---

Well, I think it is not really feasable. Any of these technics and every other one you didn't mention like Flash, ASP, etc does require it's own runtime. Just because it is installed in a lot of client machines already does not mean that you will not have to make sure it is and take actions if it isn't. Also some of these like .Net will be limited to Windows clients only if you are not a Geek and want to go through the hassles of using Mono (and possibly Wine) which I'm sure is no option for a commercial application. 
Why the LabVIEW runtime would need a system restart is a bit miraculous to me but it's probably some dependancy on the huge underlying technology around the network variable engine, and other similar things, which I think NI could quite easily decouple from the LabVIEW kernel so that it is not really a hard dependancy at all. It is not a technology I would consider so important that no LabVIEW application could exist without it especially for web served applications. In fact I have until now not used the network variable or datasocket at all and still created some heavily networked applications so far.

Rolf Kalbermatter

Message Edited by rolfk on 09-21-2007 08:30 PM

[Dennis_Knutson]

.Net and java require run-times as well. While microsoft includes .net on it's pc's, depending on which os you are using, it's not always the correct version and sometimes you are required to download a new one. In some versions of windows, microsoft was required to remove it's java engine and I have had to download that as well. I'll get messages about needing to update my flash player or windows media player for some content.

I don't believe that re-starting the pc is necessary after downloading the LabVIEW run-time. At least it's not when I've placed an exe on a pc without the correct run-time. That would be something to check with the remote panels but I don't see how having a run-time can be avoided.

[Ben]

Rolf wrote

---

In fact I have until now not used the network variable or datasocket at all and still created some heavily networked applications so far.

---

GO Rolf!

We have an expression used often in our office, "We don't need no stinking shared varaibles!"

I have to confess that I do use datasockets. They are a nice way to get at the FP I/O without knowing the IP address at development time.

RE:THe download for web-access

That download is a rather amazing chunk of code. It effectively moves the GUI updates to the viewers machine and only passes the required data updates.

Ben

[rolfk]

---

@Ben wrote:

I have to confess that I do use datasockets. They are a nice way to get at the FP I/O without knowing the IP address at development time.

RE:THe download for web-access

That download is a rather amazing chunk of code. It effectively moves the GUI updates to the viewers machine and only passes the required data updates.

---

Well, the remote debugging is simply a smart extension to that

As to FP acess, I've used the old style Fieldpoint VIs which used strings to create FP tags and that worked equally well with my own poor mans tag engine that could be configured at runtime.

The new VISA like Fieldpoint VIs are just as easy in that respect at least when used with LabVIEW 8.2. I provide a string based configuration file and the string gets then automatically translated into a Fieldpoint resource just as what happens with VISA resources. No need to hardwire Fieldpoint variable names at all. And the IP address is inherently encoded in that Fieldpoint IO point name through the according .iak file.

And the resulting code works equally well on my development machine accessing the Fieldpoint IO points over the network as well as on a CompactFieldpoint RT controller. Just switch the target and execute it.

Rolf Kalbermatter

Message Edited by rolfk on 09-21-2007 09:19 PM

[Ben]

HI Rolf,

I may be wrong but I BELEIVE the FP units server their I/O via a datasocket server that runs on the FP unit. That is why I confessed that I do use datasockets.

Ben

[rolfk]

---

@Ben wrote:

HI Rolf,

I may be wrong but I BELEIVE the FP units server their I/O via a datasocket server that runs on the FP unit. That is why I confessed that I do use datasockets.

Ben

---

I'm not sure about the exact details either but I believe the FP network IO talks rather a protocol that NI calls or at least used to call Logos and DS is strictly spoken a subset of that. 

Rolf Kalbermatter

[TedAnderson]

Thanks to all of you for your feedback, but especially to LV_Pro, for addressing not only the message subject, but also for providing a generic solution as to how to address our client's requirement that their customers not need to download or install any additional software.  Yes, there are numerous other applications that require runtime libraries or browser add-ons, but odds are that any random internet-enabled computer already has those installed, and does not have the LabVIEWruntime installed.  It's just not an option the client is willing to pursue.  The client would gladly pay for as many concurrent licenses as it would take to satisfy demand.

 It looks like CGI scripting may pave the way.  We have no need to communicate with hardware across the web.  Our program is essentially just a calculator that takes a dozen or so physical parameters and generates a graph.   As I infer from what you have written, and from what little I know about CGI, there we could load our LabVIEW executable and one or more accompanying CGI scripts onto a web server, even a server operated by a web-hosting company.  Whenever a customer of our client would land on a particular web page, enter or adjust some numbers, and hit a "graph" button, the CGI script would launch an instance of our compiled labVIEW appication and interact with it.  Once the graph was generated by the .exe, the CGI would grab it and present it to the web client, right?  Presumably several instances of the LVexe-CGIscript duo could be started and run simultaneously on the same server, adjusting to demand.

The web server would obviously need to have the LV runtime library installed.  Can you say more about the licensing requirements/implications here?

Possible choices of scripting languages would be Perl, PHP, Python, and ???? Does LabVIEW play better with one scripting language better than another? Do you have a personal preference? 

Are there any significant drawbacks to this CGI-scripted approach?

Thanks again to all.
Ted

[Dennis_Knutson]

Can't directly answer your questions but Jeffrey Travis wrote a book called "Internet Applications in LabVIEW" several years ago and before LabVIEW had the remote panel option. There was quite a bit about scripting and the Internet Toolkit. It might be worthwhile trying to find a copy.