Ashley, Isn't it for the app dev team - rather than the standards body or even the browser team - to decide whether the UI thread should wait on the server?
I see it like this: The user, with the app as middleman, is conversing with the server. Just as we want modal dialogs because sometimes it makes sense to say "Answer this before proceeding", sometimes we want a synchronous call in the main thread (because we want an answer from the server before proceeding). Sure, I can present a dialog as non-modal - but then I've got to manage the loose-ends if left unfinished. Maybe I can toss all that into a cookie - and maybe I can't. Having a modal dialog as an option allows us to simplify the code and avoid a lot of what-happened-to-my-data calls to the help desk. For me, it's the same with calls to the server. Common use-cases are log-in and master/parent-object creates. In my apps, the UI depends on user-specific config that is returned upon log-in. As well, there are instances where creating a parent object precedes creating child objects and it just creates a dozen headaches to let the user proceed without confirmation that the parent exists server-side. I agree the goal is to model as much as possible as asynchronous. My issue is that there are still real-world, practical applications for S-JAX and that identifying those is the app developer's job, not W3C's. Heck, why not go the other way and deprecate AJAX now that web workers make background threads a first-class object available for any processing? ;-) Best, George
