So the plan was...
1. Client connects to a page
2. Web server connects to CMX (either Web Sockets (WS) or Ajax)
3. CMX sends the data to the web server
4. Web server constructs page and sends back to client[/list]
There are a number of potential problems/features...
1. CMX probably has limits on the number of WS connections it can handle.
- Could cache the result, use the cache and only create a new connection if the cache is no longer being updated
2. CMX WS/http isn't secure
- Use firewall to limit access to web host only
3. If the client supports it you could use WS back to the client for updates too (gauges page would be a prime candidate)
- That should give near the fastest data updates possible
4. Would setting up the connection back to CMX delay the page load time too much for the client?
5. PHP doesn't have a WS client/server built-in, so need to find a suitable library
6. Is all the required data available from CMX via the API?
Steve, I know you haven't documented the API, but here's a suggestion for the future (like you haven't got enough to do!)...
In addition to the 'fixed' data sets, how about a custom option, where via WS (or HTTP Ajax), you can 'subscribe' to a set of values. CMX then sends a WS message for the initial data set, then a further message whenever one (or more) of the subscribed values changes (for Ajax it just returns the requested data), or at a requested interval. Oh, and while you're at it, secure the connections so they require authorisation
That's as far as I ever get, one day I may find the time to create a test implementation.
Thoughts?
