On 2014-12-11 2:17 PM, Alex Russell wrote:
On Thu, Dec 11, 2014 at 11:04 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com <mailto:ehsan.akhg...@gmail.com>> wrote: On 2014-12-11 2:03 AM, Jonas Sicking wrote: On Wed, Dec 10, 2014 at 6:22 PM, Alex Russell <slightly...@google.com <mailto:slightly...@google.com>> wrote: On Wed, Dec 10, 2014 at 5:48 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com <mailto:ehsan.akhg...@gmail.com>> wrote: On 2014-12-10 7:45 PM, Jonas Sicking wrote: On Wed, Dec 10, 2014 at 4:22 PM, Jonas Sicking <jo...@sicking.cc> wrote: On Wed, Dec 10, 2014 at 1:02 PM, <slightly...@google.com <mailto:slightly...@google.com>> wrote: 2) Users could more easily write infinite loops between SWs, since at no point would they be guaranteed to bottom out at the network. I'm more worried about the memory implications for low-spec devices of the russian-doll design for SW fetches. We've avoided it thus far for these reasons. How does navigator.connect() address this problem? In Ehsan's proposal SW from site A would do a fetch() which starts the SW from site B. In the navigator.connect() proposal the SW from site A would do a navigator.connect() which starts the SW from site B. So the same number of SWs seem to be started, the only difference is the API that's used to start them, no? Hmm.. actually navigator.connect() does actually partially address this problem. It allows site A to talk to site B without using fetch() at all. Thus enabling A to avoid using the A SW at all. Though that particular goal could be reached by adding some of the optimizations that we talked about early on in SWs design. I.e. the ability for a SW to add rules like "for this set of URLs, never wake me up and instead go directly to the network". Yeah, I suspect we may need to consider some optimizations along these lines for other reasons too. I have a strong preference to consider that question independently of what we do for cross-origin service composition. I'm fine with considering that separately. But we can certainly look at optimizing away starting the initiating's site's SW separately. But adding new APIs to work around lack of optimizations in existing APIs doesn't seem like a good path forward. The notion that a SW author will need to be savvy to what's in another SW's caches (or, worse, the version of their SW) without the ability to have a preamble conversation (ala postMessage(), which is what n.c() proposes) is...disconcerting. I don't know how that becomes useful. I don't think anyone has proposed that there's cross website knowledge about what's cached and what's not? Yes, that's definitely not what I was proposing. Let's imagine B wants to access an HTTP service from A (https://a.com/apis/whatnot), and they both have a SW. B's SW needs to make a decision today on whether or not to let the request to go to the network. At that point, B's SW is oblivious as to whether the request would be satisfied by A's SW if it chooses to let it go to the network, the same way that it's oblivious if it's going to be handled by some kind of an HTTP cache along the way. If it chooses to let the request go to the network, the proposal is to let the request be handled by A's SW first, and A's SW will make the decision on whether to let the request go to the network. If it makes that choice, the request will go to the network as there is no other candidate SW. The composition of SW's for fetch is an interesting problem, but I'm entirely unconvinced that it's important. For static resources, B's SW can cache resources from A.com and, without any extra SW spin-up, know what resources it has.
Hmm, I wasn't talking about static resources at all. I think the current SW spec gives us everything we need for same and cross origin static resources.
For the purposes of API composition, either this (or navigator.connect()) will do.
OK I'm glad I wasn't missing anything. I still think it would be very nice to avoid adding a new API and making it possible for existing code to take advantage of a locally installed SW for A in the above example.
Cheers, Ehsan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
