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

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.

But my point is that the extra 5ms delay because a previous request was 
already underway via a sync database call and so the network request 
couldn't be sent right away is going to be swamped by the multiple 200ms 
round-trip times involved in the actual network request. For some authors, 
the simplicity of doing sync API calls will outweigh the benefit of 
avoiding those 5 milliseconds.


Anyway, my argument isn't really that we should have sync APIs in 
ServiceWorkers. I'm just saying we shouldn't change SharedWorkers.

What is exposed to ServiceWorkers is up to ServiceWorkers and the spec 
that put the [Exposed] annotations on the interfaces, I would presume. 
Right now, nothing says [Exposed=ServiceWorker], so nothing is exposed. 
When we go through adding the Exposed annotations, we should just not add 
it for things that ServiceWorkers don't want.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 30 July 2014 19:37:20 UTC