On 27/10/2009, at 12:24 PM, Ian Hickson wrote:
I would expect server-side implementations to translate incoming WebSocket connections into appropriate internal connections; e.g. if Example Corp uses RPC extensively internally in their datacenters, a front-line servercould receive a long-lived WebSocket connection (speaking that site's subprotocol) and translate it into short-lived RPC on the backend. However, that would be layered above WebSocket just like this kind of thing is layered above hanging-GET systems today.
Yeah. In theory it would be nice if, for example, a corporate or ISP proxy could "manage" a bunch of WS connections back to a third-party service provider, but there's a lot of risk and overhead to going down that path, and not a tremendous amount of benefit.
I suspect most of the intermediary cases that are going to come up for WS in the near future are going to be server-side (like HTTP accelerators/reverse proxies), and they're already under the control of the server, so they can coordinate.
-- Mark Nottingham http://www.mnot.net/
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.