This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13763 - The WebSocket API should provide a polling mechanism too. Only event based capture messages is not good because if a method in a JS-Class send a message the reply arrive in the event handler. The event handler has no access (if no global var exists) to th
Summary: The WebSocket API should provide a polling mechanism too. Only event based ca...
Status: RESOLVED WONTFIX
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebSocket API (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: public-webapps-bugzilla
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-12 07:31 UTC by contributor
Modified: 2011-08-13 02:45 UTC (History)
6 users (show)

See Also:


Attachments

Description contributor 2011-08-12 07:31:04 UTC
Specification: http://www.whatwg.org/specs/web-apps/current-work/complete/network.html
Multipage: http://www.whatwg.org/C#the-websocket-interface
Complete: http://www.whatwg.org/c#the-websocket-interface

Comment:
The WebSocket API should provide a polling mechanism too. Only event based
capture messages is not good because if a method in a JS-Class send a message
the reply arrive in the event handler. The event handler has no access (if no
global var exists) to the class instance who send the request. With a polling
mechanism the class instance can wait for a reply and with webworkers there
should be no problem with waiting and polling.

Posted from: 93.217.122.57
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0
Comment 1 ReneEspenhahn 2011-08-12 09:19:02 UTC
A few additions:

Insteadt of a polling mechanism it could be alternative registered an object which will be passed to all event-handlers e.g.

var socket = new WebSocket(...);

socket.onmessage = function(event, myObject)
{
  ...
}

...

or another alternative is a waiting function on the object insteadt of polling. E.g.

var socket = new WebSocket(...);

socket.send(...);
var reply = socket.waitForData();

But in this case only one event handler (onmessage) will be used. After a reply is arrived there must be checked which reply was it.
Comment 2 ReneEspenhahn 2011-08-12 10:08:03 UTC
The second comment with the idea of "myObject" is superfluous. I have found a way to do this now. But the other two my be a thought worth.
Comment 3 Aryeh Gregor 2011-08-12 17:13:30 UTC
There's no way we'll add polling.  Polling in JavaScript is a terrible, terrible idea, because as long as script is running, the page (possibly the whole browser) is frozen.  That's why everything is event-based: JS is on the same thread as layout, and nothing can render as long as JS is running.

If you need access to a specific variable, try nesting your functions.  For instance:

function setUpSocket() {
    var myObj = initializeObject();
    // set up websocket
    s.onmessage = function() {
        // Do processing that includes access to myObj
    }
}

This is awkward sometimes, but it works.
Comment 4 ReneEspenhahn 2011-08-12 17:31:20 UTC
If the WebSocket connections is managed by a Web Worker then no page freeze occur and polling might be possible. 

I have found already the solution like you mentioned with nesting. Thanks.

Nice Weekend.
René
Comment 5 Aryeh Gregor 2011-08-12 21:39:46 UTC
AFAIK, IndexedDB exposes synchronous APIs that are only usable in Web Workers.  That's something that should be doable for WebSocket, and might be a good idea.  We don't want to require polling in that case, though -- just make it block.
Comment 6 Ian 'Hixie' Hickson 2011-08-13 02:45:44 UTC
It's easy to do this already:

   var queue = [];
   websocket.onmessage = function (event) {
     if (queue.length)
       queue.shift()(event);
   };

   // to send and then wait for response:
   websocket.send('foo');
   queue.push(function (event) {
     // rest of function goes here
   });

...or some such. Basically works like polling but without having to worry about missing other events if you have other things going on.

(code above is untested so may have syntax errors)