Steve, > On Jan 15, 2019, at 3:08 PM, Stephen J. Orth <[email protected]> > wrote: > > Not sure I understand what you are saying, would you be able to provide me > with a high level overview of what you are thinking?
HTTP is a request/response protocol where the server only responds to requests from the client. Websockets are full duplex and bi-directional meaning either side of the connection can both send and receive asynchronously. See http://blog.arungupta.me/rest-vs-websocket-comparison-benchmarks/ > > Our Server will be performing analytics' and at some point it will trap on a > condition that needs to be communicated to the shop floor. For example, a > machine has been idle for more than 5 minutes. > > When this event is flagged, the server needs to tell the browser on the > floor, associated with this machine, to take a specific action. Basically the > browser will need to present a different window for the operator to respond > into. > > So I'm just trying to understand how the HTTP idea you presented would work > in this situation... This can be achieved in a HTTP/browser interface without much trouble. I think all you would need to do is set a timer for your web interface to periodically check with the server for a change in state. Probably not as efficient as websockets, but a fraction of the development effort unless you already have a websocket server implementation ready to go. Here is an example of using a JavaScript timer to perform some action, e.g. a periodic http call to your server. https://javascript.info/settimeout-setinterval John DeSoi, Ph.D. ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
