Re: [w3c/ServiceWorker] Remove foreign fetch (#1188)

Storage security does limit a lot of use cases, but I continue to believe very strongly that there's a ton of use cases for foreign fetch that make sense with per-origin sharding.

For example, if I want to make an offline-capable recently-listened/"scrobbler" service that your/any website can post currently listening music to, what are my options? I can use something custom & fancy like [Commlink](https://github.com/GoogleChromeLabs/comlink) & it's implicit internal protocols to message an iframe. But I'd way rather, when I load my music player, give it a URL it can use to post tracks into. They can do whatever login flow is needed, and from then on, your music player app would be able to use foreign fetch to post new tracks or get a list of it's own recently listened to tracks from my recently-listened service. The SW can store & foreward this data.

The architectures enabled by Foreign Fetch are so much better than the alternatives, make the web really offline capable. I hope beyond hopes we can stop saying that per-origin caches make Foreign Fetch pointless. Yes, that does obstruct some use cases, but for many, re-downloading the data, re-logging in is not a problem at all, and the architecture of it is 100x "more web", more http-centric, versus having to get fancy. Developers know HTTP. Please, let's give them the capability to use HTTP across origins via ServiceWorkers.

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