W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2014

Re: Move sync APIs out of "Worker" into "SyncWorker"

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 30 Jul 2014 16:47:34 -0500
Message-ID: <CAAWBYDAMG4cEeqCqx5RmyQNcaArjb-1PTgvoZSHaYESEivsbAg@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Jake Archibald <jaffathecake@gmail.com>, public-script-coord <public-script-coord@w3.org>
On Wed, Jul 30, 2014 at 2:36 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Tue, 29 Jul 2014, Tab Atkins Jr. wrote:
>> On Tue, Jul 29, 2014 at 12:47 PM, Ian Hickson <ian@hixie.ch> wrote:
>> > On Tue, 29 Jul 2014, Jake Archibald wrote:
>> >> New tabs using that ServiceWorker may be open or may open while
>> >> you're blocking. Baaaaad slowwww baaaad.
>> >
>> > I totally agree that it'd be bad to be slow (though honestly, a sync
>> > call to a local database isn't generally going to be slower than a
>> > network request, so it's not really "slow" by the standards relevant
>> > here).
>> While it's generally faster than the network request itself, it's much
>> slower than returning an *instruction* to make a network request, which
>> is what a service worker actually does.
> Well, it's what you hope authors will do. I'm sure plenty will be doing
> the fetches manually.

SW purposely doesn't make that easy, so I doubt they will.  It *does*
make it easy to resolve the request with a promise for a response,
which does what we want.

Received on Wednesday, 30 July 2014 21:48:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC