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?  ;-)


Reply via email to