I have a module that requires the loading of a dll, this dll is licenced for each computer that runs the processing. I have slaved (and finally achieved ) a way to get the results or rather the displays that the dll produces within an Ignition Module. However my concern at the moment is where does the processing take place (client or server) . Do I need to install the dll on each machine, or can I run the dll on the server and force the client to interact with a mirrored version of the results .
If you want to make sure the .dll is only accessed on the gateway machine, make sure it’s only accessed from jars that do not have a designer or client scope.
Restrict your .dll usage to jars with , and then use RPCs (section 4.6 of the Programmer’s Guide) or push notifications (section 4.7) to get the information back to the designer or client. This will also let you have your Designers/Clients on non-Windows machines – you’ll only have to insure your Gateway machine is compatible with the .dll.
Thanks for that, but I may have misnamed the topic.
The crux of the matter is that the dll produces a .NET window, which using some Java “Black Magic” I am able to port and contain within the Java Panel. I wish for this .NET window to appear (can be copied) within the client window, without any of the processing occurring on the client side. Mouse actions can easily be ported through, but the display is what I care about.
The dll does some weird 3D rendering based on a large data-set and I would rather simply have the client see the end result, than have to do some processing on his side.
Is there some sort of screen mirroring system available?
Black magic, indeed.
The first thing I would try is the mobile module. The Java rendering is done on the Gateway, and the mobile client is actually loading a web page. Although it’s really intended for cell phones and the like that can’t run Java, you can run it on desktop machines.
There are a couple of downsides to this approach, and it may not suit your needs. One is that the whole client (for that machine) becomes the mobile module. If the black magic dll is only a small part of what your client sees, you’re adding extra complexity for a small gain. (Or you run two clients on the same machine, a regular client and the mobile client, which may not give the greatest user experience).
Another downside is if you have a lot of clients. Because all the processing (not just for the dll) is shoved onto the gateway, plus a little more processing to do our own mobile module black magic, your gateway can get bogged down much faster than with regular clients.
If you can make your .dll output into a web page, there’s another way to go. Ignition 7.7 will have a Web Browser component that can display web content in a regular client, including flash and silverlight. Your web server on the gateway will need to handle security (ie restricting IP addresses, etc.), but you will be able to run regular clients and have the client processing done by the client, while having the .dll processing on the Gateway.
With regards to the processing the dll actually fetches a majority of the data from dedicated local servers, so with regards to the gateway server, i doubt it will get bogged down. I doubt that I can get the .NET control to a webpage due to the lack of acess I have to the dll, and the various contents therin. I am sure I can use some kind of .ASP magic to get the .NET control within a webpage, but I would rather avoid using an html server as well, although at worst case, I may have to resort to it. In that regard, how long until we see the Ignition 7.7.
I just dont feel this addresses my concern however. I need to have a display in the client side, that mirrors the display on the gateway. The processing is not the issue the raw issue is that because the dll relies on data obtained from local servers, I cannot access the data from a client application. As a result I could either rewrite the displays and have any client streaming the raw data (which I would rather not do) or have a display in the gateway server which mirrors the output from the already coded dll.
PS if this seems very specific and unusual, imagine how I felt when I was told these specifications by those in the higher positions