> On Jan 15, 2019, at 3:08 PM, Stephen J. Orth <> 
> 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

> 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.

John DeSoi, Ph.D.
4D Internet Users Group (4D iNUG)

Reply via email to