Re: Server-Sent Events contradiction
On Wed, 2 Jan 2013, Glenn Maynard wrote: > On Wed, Jan 2, 2013 at 4:23 PM, Ian Hickson wrote: > > > > Since none of the browsers I could test reconnect for 500s currently > > as far as I can tell, I've changed the spec to not make 5xxs > > reconnect. The server load issue seems like a pretty big deal. > > Ordinary exponential backoff deals with the server load issue. Exponential backoff is a pretty horrible user experience. It basically doesn't work in UI, especially for transient problems. > It doesn't make sense for a transient error to cause the connection to > permanently fail. We're not really talking about a transient error, though. We're talking about a situation where you connect and immediately have a problem, or the connection drops, you try to reconnect, and _then_ you immediately have a problem. > All this does is make web developers do it themselves, which we > shouldn't need to deal with. I would rather make Web devs who want this to reconnect have their error case for the EventSource URL a 200 OK with the right type that then drops the connection right away, than hammer the server so hard that the Web dev can't log in to fix the problem in the first place. (Or, even better, they can simply not open the incoming connection until the problem is resolved -- that will also cause attempts to reconnect.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Server-Sent Events contradiction
On Wed, Jan 2, 2013 at 4:23 PM, Ian Hickson wrote: > Since none of the browsers I could test reconnect for 500s currently as > far as I can tell, I've changed the spec to not make 5xxs reconnect. The > server load issue seems like a pretty big deal. Ordinary exponential backoff deals with the server load issue. It doesn't make sense for a transient error to cause the connection to permanently fail. All this does is make web developers do it themselves, which we shouldn't need to deal with. -- Glenn Maynard
Re: exposing CANVAS or something like it to Web Workers
Another issue as come up and that is one of being able to synchronize updates of a canvas in worker with changes in the main page. For a real world example see Google's MapsGL (http://support.google.com/maps/bin/answer.py?hl=en&answer=1630790) Apparently MapsGL uses 2 canvases and/or some DOM objects overlayed on top of each other. Dragging the mouse moves objects in all of those layers and they need to move simultaneously to have a good UX. You can imagine issues if a canvas is being rendering to from a worker. How would the user guarantee that changes from the worker are synchronized with changes to the DOM in the main thread? Similarly, let's say you have 2 canvases and are rendering to both in a worker. Does context1.commit(); context2.commit(); guarantee you'll see both commits together? Random thoughts *) Leave things the way they are and add another mechanism for syncing? In other words, by default things are not sync. Through some other API or settings the user can opt into getting synchronization *) Look at OpenGL "swap groups" as inspiration for an API? http://www.opengl.org/registry/specs/NV/wgl_swap_group.txt http://www.opengl.org/registry/specs/NV/glx_swap_group.txt *) Consider an 'oncommit' or 'onswap' event on 'Window'? The idea being you want to give the main thread a chance to update stuff (DOM elements) in response to a worker having called 'commit' on a canvas. Of course not sure how that would work if you have 2 workers each rendering to a different canvas. Note: I haven't thought through these issues at all and I've personally not had to deal with them but it seems clear from the MapsGL example that a solution will be needed for some subset of apps to have a good UX. I know for example there's game engine that has API to keep DOM elements located relative to game objects being rendered in a canvas to make it easy to give HTML based stats on the game objects as opposed to having to render the stats manually with canvas. On Fri, Nov 16, 2012 at 8:35 PM, Ian Hickson wrote: > On Fri, 16 Nov 2012, Charles Pritchard wrote: > > > > > > > > > > http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0199.html > > > > Seems like we might use requestAnimationFrame in the main thread to > > postMessage to the worker as an alternative to using setInterval in > > workers for repaints. > > The idea in due course is to just expose rAF in workers. Please do read > the e-mail above, which actually mentions that. > > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > >
Re: Server-Sent Events contradiction
On Sun, 30 Dec 2012, Bill Thiede wrote: > > The Server-Sent Events at > http://www.w3.org/TR/2012/CR-eventsource-20121211/ states under the IANA > considerations / Security considerations section: > > "Servers can be overwhelmed if a situation develops in which the server > is causing clients to reconnect rapidly. Servers should use a 5xx status > code to indicate capacity problems, as this will prevent conforming > clients from reconnecting automatically." > > However, under section "5 Processing model" it is stated: > > "HTTP 500 Internal Server Error, 502 Bad Gateway, 503 Service > Unavailable, and 504 Gateway Timeout responses, and any network error > that prevents the connection from being established in the first place > (e.g. DNS errors), must cause the user agent to asynchronously > reestablish the connection." > > My guess is section 5 was updated more recently and the IANA section was > overlooked. I know there are 5xx errors not listed explicitly, which > would then trigger the "Any other HTTP response code not listed here > must cause the user agent to fail the connection," but I doubt that a > 501 or 505 are the suggested solution here. Good catch. Since none of the browsers I could test reconnect for 500s currently as far as I can tell, I've changed the spec to not make 5xxs reconnect. The server load issue seems like a pretty big deal. It still says to reconnect in the case of an interrupted connection though, or if the connection couldn't be established in the first place, so going through a tunnel should still work fine. Updated text is at: http://whatwg.org/html#event-source-network-errors-reconnect > PS I'm emailing, because the 'Feedback Comments' form on the web page > returned 'ERROR' on my attempt to submit. Not sure who to notify of > that problem. The error reporting widget on the WHATWG spec above should work, FWIW. E-mail is fine too though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[html-templates] Typos
Hi, I noticed the following typos in the HTML Templates draft [1]: * Under “Definitions,” “If DOCUMENT does not have a browsing context, Let…” (should be “let”). * Same section, “the stack of open elements is said be have” (seems to miss “to”). * Sometimes the word ”html” is used in lowercase, but not always referring to the standard. It would be good to check for correct use in the document, and to use capitals for references to the standard, and a monospace font for references to the element. * Inconsistent spelling of “insertion mode”. Headings, even for those whose levels don’t use title case, seem to always say “Insertion Mode,” while the copy following it says “insertion mode.” This seems inconsistent either when it comes to the headings (as they’re not all or completely using title case) or the copy (which should then also refer to “Insertion Mode”). HTH, best, Jens. [1] http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html -- Jens O. Meiert http://meiert.com/en/
Affiliation change and Streams API status
Hi all,this is to announce that my affiliation has changed and I no longer work for Microsoft. I will remain part of the WG as an invited expert, and will continue on as editor of the Streams API spec. I've recently made a set of changes to the Streams API[1] and believe the spec is feature complete in breadth and will be ready for FPWD. I expect to start moving the spec towards FPWD soon. Thanks, Feras [1]. http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm
Server-Sent Events contradiction
The Server-Sent Events at http://www.w3.org/TR/2012/CR-eventsource-20121211/ states under the IANA considerations / Security considerations section: "Servers can be overwhelmed if a situation develops in which the server is causing clients to reconnect rapidly. Servers should use a 5xx status code to indicate capacity problems, as this will prevent conforming clients from reconnecting automatically." However, under section "5 Processing model" it is stated: "HTTP 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, and 504 Gateway Timeout responses, and any network error that prevents the connection from being established in the first place (e.g. DNS errors), must cause the user agent to asynchronously reestablish the connection." My guess is section 5 was updated more recently and the IANA section was overlooked. I know there are 5xx errors not listed explicitly, which would then trigger the "Any other HTTP response code not listed here must cause the user agent to fail the connection," but I doubt that a 501 or 505 are the suggested solution here. Bill PS I'm emailing, because the 'Feedback Comments' form on the web page returned 'ERROR' on my attempt to submit. Not sure who to notify of that problem.
