Re: [slightlyoff/ServiceWorker] consider allowing multiple worker thread instances for a single registration (#756)

Several thoughts on allowing multiple SW instances.

 - It's remove the meaning of "this.addEventListener('fetch'", what will be the meaning of "this." ? A random SW scope ? So it could be a good thing to change this syntax to register handler and avoid confusions.

 - It could be a bad thing for this case:
 1: Tab_1 get "test.js" wich has never been cached
 2: fetch handler of SW_1 send the request GET "test.js"
 3: Tab_2 request also "test.js" (during the request of "test.js" of Tab_1)
 4: fetch handdler of SW_2 (second SW because the first is occupied) send the request GET "test.js"
 5: SW_1 get the response and cache "test.js"
 6: SW_2 get the response and cache "test.js"

      Result: 2 requests to the server, 2 caching operations ? Or i miss something ?

 - This open the door to create a process for each fetch request ?

 - As said by wheresrhys, call indexedDB to store globally a state on each fetch or postmessage event can become a pb for performances ?

 - Also the solution wich consists to use a SharedWorker uppon many ServiceWorkers instances to coordinate things...become a little bit complex no ?

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/756#issuecomment-237875153