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.
Again, there's still an important difference in syntax, which might
accomplish some other goals that you are aiming for?
I'm curious to know if the new syntax accomplishes anything else that I
may have missed.
Also, I'd like to reiterate that not using a new syntax will allow
existing code to use SWs without any change, but a change in syntax
means that all of the existing code using XHR (and soon fetch) needs to
be rewritten to use navigator.connect, and perhaps fall back to actually
talk to the network if the SW on the other side is not available to
respond, which seems a lot more complicated.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
