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

Re: IndexedDB, what were the issues? How do we stop it from happening again?

From: Alex Russell <slightlyoff@google.com>
Date: Thu, 14 Mar 2013 19:19:25 -0700
Message-ID: <CANr5HFVz7eq83fMsHLzH1csxLjO5=kYLC6OyxCWc3GFK6vQw2Q@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Glenn Maynard <glenn@zewt.org>, Tobie Langel <tobie@fb.com>, Jarred Nicholls <jarred@webkit.org>, public-webapps WG <public-webapps@w3.org>
On Thursday, March 14, 2013, Tab Atkins Jr. wrote:

> On Thu, Mar 14, 2013 at 6:36 PM, Glenn Maynard <glenn@zewt.org<javascript:;>>
> wrote:
> > On Thu, Mar 14, 2013 at 1:54 PM, Alex Russell <slightlyoff@google.com<javascript:;>
> >
> > wrote:
> >> I don't understand why that's true. Workers have a message-oriented API
> >> that's inherently async. They can get back to their caller "whenevs".
> What's
> >> the motivator for needing this?
> >
> > Being able to write synchronous code is one of the basic uses for
> Workers in
> > the first place.  Synchronously creating streams is useful in the same
> way
> > that other synchronous APIs are useful, such as FileReaderSync.
> >
> > That doesn't necessarily mean having a synchronous API for a complex
> > interface like this is the ideal approach (there are other ways to do
> it),
> > but that's the end goal.
> Yes, this seems to be missing the point of Workers entirely.  If all
> you have are async apis, you don't need Workers in the first place, as
> you can just use them in the main thread without jank.  Workers exist
> explicitly to allow you to do expensive synchronous stuff without
> janking the main thread.  (Often, the expensive synchronous stuff will
> just be a bunch of calculations, so you don't have to explicitly break
> it up into setTimeout-able chunks.)
> The entire reason for most async (all?) APIs is thus irrelevant in a
> Worker, and it may be a good idea to provide sync versions, or do
> something else that negates the annoyance of dealing with async code.

My *first* approach to this annoyance would be to start adding some async
primitives to the platform that don't suck so hard; e.g., Futures/Promises.
Saying that you should do something does not imply that doubling up on API
surface area for a corner-case is the right solution.

> > (FYI, the messaging in Workers isn't inherently async; it just happens to
> > only have an async interface.  There's been discussion about adding a
> > synchronous interface to messaging.)
> Specifically, this was for workers to be able to synchronously wait
> for messages from their sub-workers.  Again, the whole point for async
> worker messaging is to prevent the main thread from janking, which is
> irrelevant inside of a worker.
> ~TJ
Received on Friday, 15 March 2013 02:19:52 UTC

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