On Thu, Dec 11, 2014 at 11:04 AM, Ehsan Akhgari <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> >> 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? >> > > 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. For the purposes of API composition, either this (or navigator.connect()) will do. Both seem entirely unrelated to static routing for resources. > > > For one, it allows you to offer local services that don't map to > > HTTP. This is both blessing and curse, but I think it is likely to > > be useful at the limit; e.g., reducing serialization overhead via > > transferrables. > > On using services that do not map to HTTP, I'm not sure I understand why > that is a goal. If the real goal is to have a side channel to talk to the > SW without having a corresponding HTTP API, that is possible with my > proposal if A's SW declares that it can handle the > "/apis/sw-specific-backchannel" > scope, for example (in that case letting that request hit the network will > result in a 404 as that API scope doesn't exist on A's server.) > > Reducing serialization overhead is indeed interesting, but I think that's > something better addressed in Fetch, so that we can reap the benefits both > in normal fetches and in my proposal. > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
