On 2014-12-11 2:03 AM, Jonas Sicking wrote:
On Wed, Dec 10, 2014 at 6:22 PM, Alex Russell <[email protected]> wrote:
On Wed, Dec 10, 2014 at 5:48 PM, Ehsan Akhgari <[email protected]>
wrote:
On 2014-12-10 7:45 PM, Jonas Sicking wrote:
On Wed, Dec 10, 2014 at 4:22 PM, Jonas Sicking <[email protected]> wrote:
On Wed, Dec 10, 2014 at 1:02 PM, <[email protected]> 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.
> 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
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
