Eric, I'm not sure that a web server is much load on the server. We certainly haven't seen it using much at all at this point. Peter is going to having is spewing as much info as possible in it's next iteration in order to verify what it does under a strain but at the moment it is negligible. It may be a bit more than Linuxcncrsh but profiling the two would be an interesting comparison since we haven't played with Linuxcncrsh. Also we are not (necessarily) advocating a browser-based UI to Linuxcnc. Peter was using that as an easy way to test proof of concept. For initial config and for status though it would be a good way to go. A web server doesn't have to ONLY talk to a browser. Removing the video overhead and local UI will free up quite a bit of resources so even if the web server is more overhead it will have plenty of headroom. Tom
On Nov 17, 2012, at 10:03 AM, Eric H. Johnson wrote: > Peter, > > I think there are good reasons for both approaches, which mainly come down > to whether to drive the user interface from the server side or run on the > client side. The approach I have taken is to limit as much as possible the > server side to running the real time control, making the load on the server > more deterministic and less resource hungry. This can become even more > important if lcnc can be successfully ported to less powerful ARM type > processors. They tend to be more limited not only in CPU speed but memory > availability as well. > > Thus I would really like to get the core lcnc functions (HAL, motion > control, interpreter, etc.) running on a headless Linux server install and > only connect GUIs remotely (my applications only, not a paradigm shift of > all of lcnc of course). Which of course does not preclude your approach, it > only adds to the resource requirements. > > I also utilize the user interface as the liaison to the client side > operating system, which up to this point has been exclusively Windows. The > operator only sees the Windows side, an application which looks and feels > like any other Windows application, thus the operator does not really care > what is running on the control side. Doing this more generically does of > course present some problems, but with the recent ubiquitous availability of > Linux like devices (Android, iOS, etc.) that would not seem to be a problem > going forward. > > There may be some ways around this when pushed from the server side, but I > like the user interface running as an app rather than through a browser. It > frees up a little more real estate and it basically locks the operator into > the app which occupies the entire screen. > > Your approach has many advantages as well, foremost is not needing to > generate separate packages for each platform. > > Regarding the back plot, my problem is not rendering the back plot itself, I > already have code for that. The problems I have run into are glade specific, > things are not rendering at run time the way they are drawn in the glade > environment. Components are ending up attached to parents higher in the > hierarchy than they are drawn. I have not figured out whether this is a > glade problem or something I am doing wrong. Of course I am presuming the > latter. So I am really just simplifying the layout until I can figure out > what I am doing wrong in more complex layouts. > > There are several levels of security. Securing the communications would seem > to be a simple matter of using certificates and running over https. Securing > the operator from what they should and should not be allowed is a different > matter and the responsibility of the application. Linuxcncrsh only provides > a limited form of the latter. It can limit the actions the operator can take > and arbitrates so that only one user interface is in control at any one > time. Securing the communications would be a matter of tunneling the desired > port(s) over ssh. > > Otherwise I am in complete agreement on your vision and have often made the > analogy between lcnc and the operation of a network router. > > Regards, > Eric ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
