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

I'll try and chase down those in Blink land that want sync stuff in
SharedWorkers and find out why. If it's just "sync is easier", bleh, that's
what ES7 async functions are for.

As an aside, do we make an exception with importScripts? ServiceWorker has
importScripts but with restrictions & caching built in, but it'll
implicitly cache the scripts & fail if it's called after the initial
execution. Maybe SharedWorker should have the same behaviour but without
the caching.


On 29 July 2014 19:01, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Jul 29, 2014 at 8:50 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
> > On Tue, Jul 29, 2014 at 5:30 PM, Jake Archibald <jaffathecake@gmail.com>
> wrote:
> >> Would it makes sense to do one of the following?:
> >>
> >> * Expose the sync methods on DedicatedWorker only - this would require
> usage
> >> stats of sync methods in SharedWorkers to be insignificant
> >> * Expose the sync methods on a new global SyncWorker, where
> >> DedicatedWorkerGlobalScope would be
> >> [Global=Worker,SyncWorker,DedicatedWorker], SharedWorkerGlobalScope
> would be
> >> [Global=Worker,SyncWorker,SharedWorker]
> >
> > I like the first option if we can make it fly. Jonas probably has
> > concerns. Ian will need to update HTML for the second option to work.
>
> Mozilla would be fine with the first option. I even emailed this list
> about this before we started shipping SharedWorker. However Blink (who
> at the time had the only implementation of SharedWorker) showed no
> interest in removing sync APIs from SharedWorker and so we ended up
> shipping sync APIs in shared workers.
>
> If Google+Opera shows interest in removing sync APIs from SharedWorker
> in Blink, in the form of actual patches, then I believe that Mozilla
> would follow.
>
> / Jonas
>