W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: do not deprecate synchronous XMLHttpRequest

From: Marc Fawzi <marc.fawzi@gmail.com>
Date: Tue, 10 Feb 2015 14:25:51 -0800
Message-ID: <CACioZiuKRoT35XFWUaZQqEdeT7CEgHPEyxTKZQFu7Y5Um5dcLQ@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Michaela Merz <michaela.merz@hermetos.com>, Florian Bösch <pyalot@gmail.com>, Glenn Adams <glenn@skynav.com>, Ashley Gullen <ashley@scirra.com>, George Calvert <george.calvert@loudthink.com>, "public-webapps@w3.org" <public-webapps@w3.org>
<<
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 think maybe aside from the thread-safe DOM idea, everything below that
should belong to the ES7 discussion list.



On Tue, Feb 10, 2015 at 1:46 PM, Marc Fawzi <marc.fawzi@gmail.com> wrote:

>
> 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 my iPhone
>
> > On Feb 10, 2015, at 1:09 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> >
> >> On Tue, Feb 10, 2015 at 12:51 PM, Marc Fawzi <marc.fawzi@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
> >> developers
> >
> > Developers actually have more say than any other party in this process.
> >
> > Browsers are not interested in shipping any APIs that developers
> > aren't going to use. Likewise they are not going to remove any APIs
> > that developers are using (hence sync XHR is not going to go anywhere,
> > no matter what the spec says).
> >
> > Sadly W3C and the developer community has not yet figured out a good
> > way to communicate.
> >
> > But here's where you can make a difference!
> >
> > Please do suggest problems that you think needs to be solved. With new
> > specifications that are still in the development phase, with existing
> > specifications that have problems, and with specifications that
> > doesn't exist yet but you think should.
> >
> > Looking forward to your constructive contributions.
> >
> > / Jonas
>
Received on Tuesday, 10 February 2015 22:27:00 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC