Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Glenn Adams
Given implementations already support synchronous behavior, the only reason to deprecate would be if continuing to support that behavior comes at a significant burden to future versions of these implementations. I would conjecture it is not, so I oppose deprecation on the principle that policy

[Bug 27994] New: [Shadow]: Distribution result usage examples

2015-02-10 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27994 Bug ID: 27994 Summary: [Shadow]: Distribution result usage examples Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity:

Re: [webcomponents]: Let's reach consensus on Shadow DOM

2015-02-10 Thread Anne van Kesteren
On Sat, Feb 7, 2015 at 12:25 AM, Dimitri Glazkov dglaz...@google.com wrote: So instead, I decided to start summarizing the contentious bits of the current Shadow DOM spec: https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits This is really great Dimitri, thanks. All the

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Ashley Gullen
I am on the side that synchronous AJAX should definitely be deprecated, except in web workers where sync stuff is OK. Especially on the modern web, there are two really good alternatives: - write your code in a web worker where synchronous calls don't hang the browser - write async code which

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Marc Fawzi
What? a good cop bad cop routine? Jonas asks for a constructive contribution or ideas for missing functionality in the web platform and the inventor of JS honors me with a condescending response, as if ... What the hey! Mr. Eich! I guess this explains the origin of JS: a knee jerk reaction

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Marc Fawzi
Sent from my iPhone On Feb 10, 2015, at 5:44 PM, Brendan Eich bren...@secure.meer.net wrote: Please stop overloading public-webapps with idle chatter. React and things like it or based on it are going strong. Work there, above the standards. De-jure standardization will follow, and

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Brendan Eich
Your message to which I replied is not cited accurately below by you. The text you wrote is here, in between lines: How about a thread-safe but lock-free version of the DOM based on something like Clojure's atom? So we can manipulate the DOM from web workers? With cursor support? How

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Marc Fawzi
I've recently started using something called an atom in ClojureScript and it is described as a mutable reference to an immutable value. It holds the state for the app and can be safely mutated by multiple components, and has an interesting thing called a cursor. It is lock free but synchronous.

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Brendan Eich
Please stop overloading public-webapps with idle chatter. React and things like it or based on it are going strong. Work there, above the standards. De-jure standardization will follow, and we'll all be better off for that order of work. /be Marc Fawzi wrote: How about a thread-safe but

[DOM3Events/UIEvents] Minutes from 10 Feb 2015 teleconference

2015-02-10 Thread Travis Leithead
Contents * Topicshttp://www.w3.org/2015/02/11-webapps-minutes.html#agenda * Bug 27991http://www.w3.org/2015/02/11-webapps-minutes.html#item01 * Bug 27990http://www.w3.org/2015/02/11-webapps-minutes.html#item02 * Summary of Action

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Brendan Eich
Marc Fawzi wrote: I've recently started using something called an atom in ClojureScript and it is described as a mutable reference to an immutable value. It holds the state for the app and can be safely mutated by multiple components, and has an interesting thing called a cursor. It is lock

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Michaela Merz
No argument in regard to the problems that might arise from using sync calls. But it is IMHO not the job of the browser developers to decide who can use what, when and why. It is up the guys (or gals) coding a web site to select an appropriate AJAX call to get the job done. Once again: Please

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Michaela Merz
LOL .. good one. But it's not only about whether or not s-xhr should be depreciated. It's also about the focus and scope of the browsers teams work. m. On 02/10/2015 11:28 AM, Marc Fawzi wrote: Here is a really bad idea: Launch an async xhr and monitor its readyState in a while loop and

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread George Calvert
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

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Marc Fawzi
Here is a really bad idea: Launch an async xhr and monitor its readyState in a while loop and don't exit the loop till it has finished. Easier than writing charged emails. Less drain on the soul. Sent from my iPhone On Feb 10, 2015, at 8:48 AM, Michaela Merz michaela.m...@hermetos.com

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Elliott Sprehn
On Tuesday, February 10, 2015, Marc Fawzi marc.fa...@gmail.com wrote: Here is a really bad idea: Launch an async xhr and monitor its readyState in a while loop and don't exit the loop till it has finished. Easier than writing charged emails. Less drain on the soul This won't work, state

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Boris Zbarsky
On 2/10/15 12:28 PM, Marc Fawzi wrote: Launch an async xhr and monitor its readyState in a while loop and don't exit the loop till it has finished. Per spec (and in implementations last I checked), the readyState isn't allowed to change during the loop. So all that will happen is you will

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Marc Fawzi
If readyState is async then have set a variable in the readyState change callback and monitor that variable in a while loop :D What am I missing? On Tue, Feb 10, 2015 at 9:44 AM, Elliott Sprehn espr...@chromium.org wrote: On Tuesday, February 10, 2015, Marc Fawzi marc.fa...@gmail.com wrote:

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Marc Fawzi
Async xhr with callback let's you manage the flow such that you don't do anything until a successful response from the server. Promises make it even nicer. Sent from my iPhone On Feb 10, 2015, at 9:15 AM, George Calvert george.calv...@loudthink.com wrote: Ashley, Isn't it for the

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Elliott Sprehn
On Tuesday, February 10, 2015, Marc Fawzi marc.fa...@gmail.com wrote: If readyState is async then have set a variable in the readyState change callback and monitor that variable in a while loop :D What am I missing? The event fires async, at the time we update the property. There is no way

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Marc Fawzi
How about a thread-safe but lock-free version of the DOM based on something like Clojure's atom? So we can manipulate the DOM from web workers? With cursor support? How about immutable data structures for side-effect-free functional programming? How about Will think of more Sent from

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Jonas Sicking
On Tue, Feb 10, 2015 at 12:43 PM, Michaela Merz michaela.m...@hermetos.com wrote: Blobs are immutable but it would be cool to have blob 'pipes' or FIFOs allowing us to stream from those pipes by feeding them via AJAX. Since it sounds like you want to help with this, there's good news! There's

Standards wonks and developers working together [Was: Re: do not deprecate synchronous XMLHttpRequest]

2015-02-10 Thread Arthur Barstow
On 2/10/15 3:51 PM, Marc Fawzi wrote: I wish there was an app like Hacker News where browser vendors via W3C, TAG, webapps etc engage users and developers in discussions and use up/down votes to tell what matters most to users and developers. I like this idea. I think this is one of the

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Jonas Sicking
On Tue, Feb 10, 2015 at 12:51 PM, Marc Fawzi marc.fa...@gmail.com wrote: i agree that it's not a democratic process and even though some W3C/TAG people will engage you every now and then the end result is the browser vendors and even companies like Akamai have more say than the users and

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Michaela Merz
That is good news indeed. And I am glad to help. m. On 02/10/2015 03:02 PM, Jonas Sicking wrote: On Tue, Feb 10, 2015 at 12:43 PM, Michaela Merz michaela.m...@hermetos.com wrote: Blobs are immutable but it would be cool to have blob 'pipes' or FIFOs allowing us to stream from those pipes

Staying on topic [Was: Re: do not deprecate synchronous XMLHttpRequest]

2015-02-10 Thread Arthur Barstow
On 2/10/15 3:43 PM, Michaela Merz wrote: The web-developers are the people who have to use the available browser technologies to provide what users want. And often we can't oblige because - well, browsers don't implement it for whatever reason. Michaela - this list is for technical discussions

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Marc Fawzi
How about a thread-safe but lock-free version of the DOM based on something like Clojure's atom? So we can manipulate the DOM from web workers? With cursor support? How about immutable data structures for side-effect-free functional programming? and transients! to complete the picture. I