Re: [whatwg] Websockets Client API
I went through exactly the same exercise some days ago. It turns out that the perfectly clear specification is the specification of the Javascript runtime environment, not in the particular API specification. obTangentEven in that case, I would prefer to see a separate open call. It's just cleaner to have the act of object creation separated from the act of external communication./obTangent. On 02/21/11 03:51, Robert O'Callahan wrote: On Mon, Feb 21, 2011 at 2:34 PM, Bruce Athertonbr...@callenish.com wrote: Perhaps you are reading a different spec than I am. The only language I see about queuing tasks involves changing the ready state on the Websocket object. There is nothing in there about waiting until a block of other Javascript code has run before making any other event callbacks. http://dev.w3.org/html5/websockets/#feedback-from-the-protocol For every event in that section, the user-agent must queue a task to fire the event. None of the other sections describe any events. Let me see if I follow the perfectly clear line of reasoning you are using. Your assumption is that a Websocket connection will only be loaded in an event handler like window.onload. In HTML5-compliant user-agents, all Javascript runs in some task of the HTML5 event loop. That task must run to completion before other tasks queued by the user-agent will run. No other events will be delivered until the current event handler finishes. And the event handler that creates the Websocket object will necessarily also be where the event handlers are set on the Websocket object. By making all of these assumptions, it becomes obvious that within a browser this API is safe for callbacks. Do I have that right? Yes. You observe correctly that the Web author has to be careful to ensure that the event handlers are set on the Websocket object during the same task that created it. However, this is a fairly natural requirement that is common in the Web platform. I am reminded of a joke about mathematicians. One argues that it is obvious that claim A follows from B. The other disagrees. After arguing for an hour, the latter finally agrees that A obviously follows from B. Yeah :-). By perfectly clear I meant that the spec was unambiguous, rather than obvious to the casual reader :-). Rob
Re: [whatwg] Websockets Client API
I believed that the browser is expected to somehow magically delay the events until a callback has been registered. At least that is how it seems to work at the moment. The specification could be clearer about this. While IETF and W3C are involved in standardizing the protocol, the part you are dealing with falls in between of the two specifications. I think IETF does not usually specify APIs for the protocols, and W3C specifies browser APIs for untrusted javascript code. You are expected to look at the IETF spec and design an API that suits the environment you are programming for. You may want to look at the W3C specification, as some users may have used that API before they start using your library. However the W3C specification only reveals certain subset of the features that the IETF protocol defines. The rationale behind this is that the browser may be running untrusted code that needs to be restricted for security reasons. --Toni On Mon, Feb 21, 2011 at 12:09 AM, Bruce Atherton br...@callenish.com wrote: I know that the IETF HyBi WG is defining the Websockets protocol, but I believe that the definition of the browser API is still done through HTML5. If I am wrong, please let me know. I've been reading through http://dev.w3.org/html5/websockets/ in an effort to define a similar client interface for my Websockets library. I am a bit stuck on how a connection is established, though. According to the spec, establishing a connection is done through the Websocket object constructor on a background thread. This results in the possibility that a connection could fire its open, error, and/or close events before the user can set a handler for these events. For the open and close events one could recover based on the ReadyState of the object, albeit with additional complexity for every newly opened Websocket connection, but any error events would be lost forever. Is there a reason not to have a separate open() call? This could be done in the same asynchronous manner as described in Step 7 of the Websocket constructor. The only difference would be that the user gets the opportunity to fully configure the Websocket object before it is used to establish a connection.
Re: [whatwg] Websockets Client API
On Mon, Feb 21, 2011 at 11:38 AM, Toni Ruottu toni.ruo...@iki.fi wrote: I believed that the browser is expected to somehow magically delay the events until a callback has been registered. At least that is how it seems to work at the moment. The specification could be clearer about this. It's not magic, the spec is perfectly clear. The language about queuing a task ensures that any callback events fire after the current task (e.g. the script event handler that created the Websocket connection) has run to completion. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Websockets Client API
Forgive me if I'm overlooking something here but couldn't the same thing be accomplished by wrapping the constructor code in a try/catch block? Anthony On 02/20/2011 04:09 PM, Bruce Atherton wrote: I know that the IETF HyBi WG is defining the Websockets protocol, but I believe that the definition of the browser API is still done through HTML5. If I am wrong, please let me know. I've been reading through http://dev.w3.org/html5/websockets/ in an effort to define a similar client interface for my Websockets library. I am a bit stuck on how a connection is established, though. According to the spec, establishing a connection is done through the Websocket object constructor on a background thread. This results in the possibility that a connection could fire its open, error, and/or close events before the user can set a handler for these events. For the open and close events one could recover based on the ReadyState of the object, albeit with additional complexity for every newly opened Websocket connection, but any error events would be lost forever. Is there a reason not to have a separate open() call? This could be done in the same asynchronous manner as described in Step 7 of the Websocket constructor. The only difference would be that the user gets the opportunity to fully configure the Websocket object before it is used to establish a connection.
Re: [whatwg] Websockets Client API
On 20/02/2011 2:57 PM, Robert O'Callahan wrote: It's not magic, the spec is perfectly clear. The language about queuing a task ensures that any callback events fire after the current task (e.g. the script event handler that created the Websocket connection) has run to completion. Perhaps you are reading a different spec than I am. The only language I see about queuing tasks involves changing the ready state on the Websocket object. There is nothing in there about waiting until a block of other Javascript code has run before making any other event callbacks. Let me see if I follow the perfectly clear line of reasoning you are using. Your assumption is that a Websocket connection will only be loaded in an event handler like window.onload. No other events will be delivered until the current event handler finishes. And the event handler that creates the Websocket object will necessarily also be where the event handlers are set on the Websocket object. By making all of these assumptions, it becomes obvious that within a browser this API is safe for callbacks. Do I have that right? I am reminded of a joke about mathematicians. One argues that it is obvious that claim A follows from B. The other disagrees. After arguing for an hour, the latter finally agrees that A obviously follows from B.
Re: [whatwg] Websockets Client API
Sorry, I don't understand what you mean. The constructor is not throwing an exception in this case. The issue I am concerned with is that the Websocket object can potentially be used before it has been configured with event handlers, although it sounds like that may not be an issue in browsers. To my mind there are two solutions: include an event-handler collection as a parameter on all the constructor methods, or separate the open() call out from the constructor. For my library I think I'll opt for the latter option. On 20/02/2011 4:28 PM, Anthony Papillion wrote: Forgive me if I'm overlooking something here but couldn't the same thing be accomplished by wrapping the constructor code in a try/catch block? Anthony
Re: [whatwg] Websockets Client API
On Mon, Feb 21, 2011 at 2:34 PM, Bruce Atherton br...@callenish.com wrote: Perhaps you are reading a different spec than I am. The only language I see about queuing tasks involves changing the ready state on the Websocket object. There is nothing in there about waiting until a block of other Javascript code has run before making any other event callbacks. http://dev.w3.org/html5/websockets/#feedback-from-the-protocol For every event in that section, the user-agent must queue a task to fire the event. None of the other sections describe any events. Let me see if I follow the perfectly clear line of reasoning you are using. Your assumption is that a Websocket connection will only be loaded in an event handler like window.onload. In HTML5-compliant user-agents, all Javascript runs in some task of the HTML5 event loop. That task must run to completion before other tasks queued by the user-agent will run. No other events will be delivered until the current event handler finishes. And the event handler that creates the Websocket object will necessarily also be where the event handlers are set on the Websocket object. By making all of these assumptions, it becomes obvious that within a browser this API is safe for callbacks. Do I have that right? Yes. You observe correctly that the Web author has to be careful to ensure that the event handlers are set on the Websocket object during the same task that created it. However, this is a fairly natural requirement that is common in the Web platform. I am reminded of a joke about mathematicians. One argues that it is obvious that claim A follows from B. The other disagrees. After arguing for an hour, the latter finally agrees that A obviously follows from B. Yeah :-). By perfectly clear I meant that the spec was unambiguous, rather than obvious to the casual reader :-). Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
