On Wed, Dec 10, 2014 at 6:22 PM, Alex Russell <slightly...@google.com> wrote: > On Wed, Dec 10, 2014 at 5:48 PM, Ehsan Akhgari <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> 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? / Jonas _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
