WebSockets Gateway and JS Library
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenSRF |
Fix Released
|
Wishlist
|
Unassigned |
Bug Description
Background:
WebSockets are a standards-
Until recently, OpenSRF supported streaming responses to Mozilla-based browsers via multipart/
With no mechanism for streaming responses, we lose the ability to support long-running, real-time conversations with the client, in which case interfaces, the most obvious one in Evergreen being Vandelay, that rely on long-running streams of responses would need to be redesigned to use a polling mechanism instead.
Also in the context of Evergreen, where much of the staff client was developed even before the streaming translator existed (using the non-streaming gateway), supporting streaming going forward will allow us to continue migrating bulky call-and-response APIs to the network friendlier call-once-
Beyond streaming, WebSockets also operates over and always-on connection. This reduces the overall network traffic required to communicate over the long run with the server, which should further reduce the effects of latency, particularly on interfaces / actions where lots of network I/O is needed.
For more of this type of discussion, see my 3-part blog post, starting with
http://
Code:
I have working code for server and client (JS) components.
http://
The server runs as an Apache plugin, much like osrf_http_
WebSockets are not (currently) enabled by default, so you have to turn them on in your scripts. To activate the standard, single-browser-tab connections, add this line of code to your opensrf JS script.
OpenSRF.
Once that's set, it will just work. Note that w/ websockets, all communication is asynchronous, so setting a timeout to force synchronous mode will not work.
Very recently I added support for sharing a single websocket connection with multiple browser tabs via Shared Web Workers (http://
Shared web workers are supported by Chrome, Safari, and Opera. Firefox adds provisional support in version 28 (I've tested this), but it requires an about:config change to activate it, since the feature is still in beta (dom.workers.
To activate shared connections, use OpenSRF.
TODO:
* testing, testing, and more testing, particularly in different environments.
* more docs
* improve the install process
Changed in opensrf: | |
milestone: | none → 2.4.0-alpha |
tags: | added: pullrequest |
Changed in opensrf: | |
importance: | Undecided → Wishlist |
status: | New → Fix Committed |
Changed in opensrf: | |
status: | Fix Committed → Fix Released |
Testing with Evergreen:
There is a lot of JS code in Evergreen (dojo libs and UI code) which assume synchronous communication, which does not work with Websockets, as noted above. Because of this, it's not possible to use the OpenSRF WebSocket JS libs as a drop-in replacement for Evergreen.
Testing for now has to happen a lower level, using OpenSRF JS directly or, for the adventurous.. The browser-based staff client prototype code assumes all async and I have confirmed that it works fine with WebSockets.