Steve,

> On Jan 15, 2019, at 3:08 PM, Stephen J. Orth <s.o...@the-aquila-group.com> 
> 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:4d_tech-unsubscr...@lists.4d.com
**********************************************************************

Reply via email to