Cross origin communication and the navigator.connect API

[Nikhil Marathe]

(cross posted dev.b2g since this seems very relevant to it, but please keep
the discussion on dev.platform)

Hi All,

As part of the ServiceWorker initiative [1], Google is proposing a
`navigator.connect` API [2] to allow cross-origin ServiceWorker
communication. This post is mostly a notice to inform everyone of this
unofficial draft API.

This seems similar to our Inter-App communication API [3] and I'm sure the
authors and users of that API have feedback that should be incorporated in
a cross-web (non-b2g-specific) API. There also seems to be overlap with
some use-cases for Web Activities [4].

This is a good opportunity for us to influence how cross-origin messaging
is implemented at an early stage. If someone wants to drive this from
Mozilla's side, please "raise your hand".

Best,
Nikhil

[1]:
https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html
[2]: https://github.com/mkruisselbrink/navigator-connect
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=876397
[4]: https://developer.mozilla.org/en-US/docs/Web/API/Web_Activities

[Bobby Holley]

This API is message-passing only, and doesn't have any synchronous pieces,
right?

What, from your understanding, are the key/interesting high-level pieces of
this API that need to be sorted out?

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Jake Leichtling]

As the draft API spec
<http://mkruisselbrink.github.io/navigator-connect/> currently
stands, initial connection and ongoing communication are all asynchronous.
This is how we have initially envisioned the API, but there isn't any major
impediment to considering a synchronous piece if a compelling use case
supports it.

One key part of the API that remains to be sorted out is what will happen
when a web origin attempts to connect to a Service Worker that is not
registered. This connection attempt could either fail—perhaps without any
indication of whether the SW was not installed or rather the connection was
rejected for some other reason—or it could lead to downloading and
registering the SW. Maybe this scenario necessitates UI in some cases. This
is very much an open question.


Jake Leichtling | Associate Product Manager ☰ Chrome Apps |
jleic...@google.com | (415) 279-4508

[Bobby Holley]

On Tue, Dec 9, 2014 at 11:04 PM, Jake Leichtling <jleic...@google.com>
wrote:

> As the draft API spec <http://mkruisselbrink.github.io/navigator-connect/> currently
> stands, initial connection and ongoing communication are all asynchronous.
> This is how we have initially envisioned the API, but there isn't any major
> impediment to considering a synchronous piece if a compelling use case
> supports it.
>

Synchronous pieces are basically a non-starter IMO, which is why I wanted
to double-check that this was async.

One key part of the API that remains to be sorted out is what will happen
> when a web origin attempts to connect to a Service Worker that is not
> registered. This connection attempt could either fail—perhaps without any
> indication of whether the SW was not installed or rather the connection was
> rejected for some other reason—or it could lead to downloading and
> registering the SW. Maybe this scenario necessitates UI in some cases. This
> is very much an open question.
>

Ok. That kind of stuff isn't really my domain, so somebody else on the
Mozilla side should pick this up. Overholt - if nobody jumps on this, can
you follow up and make sure that we make an explicit decision about what to
do here?

Cheers,
bholley

[Ehsan Akhgari]

On 2014-12-10 12:21 AM, Nikhil Marathe wrote:
> (cross posted dev.b2g since this seems very relevant to it, but please keep
> the discussion on dev.platform)
>
> Hi All,
>
> As part of the ServiceWorker initiative [1], Google is proposing a
> `navigator.connect` API [2] to allow cross-origin ServiceWorker
> communication. This post is mostly a notice to inform everyone of this
> unofficial draft API.
>
> This seems similar to our Inter-App communication API [3] and I'm sure the
> authors and users of that API have feedback that should be incorporated in
> a cross-web (non-b2g-specific) API. There also seems to be overlap with
> some use-cases for Web Activities [4].
>
> This is a good opportunity for us to influence how cross-origin messaging
> is implemented at an early stage. If someone wants to drive this from
> Mozilla's side, please "raise your hand".

I am very interested in this problem, and in fact I've been thinking
about what we should do for cross origin SW communications for a while.
:-) I do support the idea but I'm not convinced that we need a
specific API to talk to the SW (such as navigator.connect.)

What I have been envisioning is allowing SWs that are registered with
the UA to respond to cross origin fetch requests made through XHR/fetch
even from documents that are themselves not controlled by a SW. The
reasoning I have for this is as follows:

Currently on the Web, the defacto way that applications talk to each
other cross origin is through XHR using CORS. See the numerous HTTP
based APIs that are developed by various organizations that are used by
Web applications right now. With service workers, we are going to have
a Web that is usable off-line, and we can also use SWs to do things such
as smarter caching on the client side. The next interesting use case
would be to enable the usage of these HTTP based APIs offline (or doing
smart caching on the client side, etc.)

I see no great reason to require Web applications to write specific code
for this, though. Let's say that my application XHRs into
<https://socialnetwork.com/get/friends> in order to get the user's list
of friends. It would be nice to allow that request to be handled by the
service worker registered for socialnetwork.com and give that SW control
over whether it wants to respond to the request without going to the
network. This has the additional advantage that people's code and all
of the ecosystem that they have built on top of XHR based APIs over the
years will just work offline once the service providers get their SWs
registered.

The downside of this approach is of course relying on the service
providers to get their SWs registered, which may require the user to
navigate to the service provider's origin, but I suppose that matches
the security model of the UA prompting for the installation of the
service worker, etc.

So I guess my biggest question so far is: what will we gain by adding
another API specifically for connecting to the service worker? Do you
think we can avoid doing that and focus on making XHR/fetch work with
cross origin SWs?

Cheers,
Ehsan

[Martin Thomson]

On 10/12/14 09:46, Ehsan Akhgari wrote:
> Do you think we can avoid doing that and focus on making XHR/fetch work
> with cross origin SWs?

I like this idea! Accomplish the basic task with the tools already at hand.

[Nikhil Marathe]

On Wed, Dec 10, 2014 at 9:46 AM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

I like this idea. It would even be possible to create some lib that used a
bit of JS reflection to auto create fully RESTful APIs from the functions
exposed to cross-origin in the SW script. But I'm getting ahead of myself :)

The fetch() based API won't be as user friendly as postMessage() for
gossiping (where the two SWs are having an entire conversation rather than
just a couple of exchanges), but it should be easy to abstract that away
into a library too so that:

var ipc = new LibIPC('//foo.com')
ipc.send("/addToCart", "itemid=4").send("/useCachedCredentialsToPay",
"authToken=baz").then(function() {}, function() {})

and underneath the lib would chain calls to fetch() and deal with response
Promises accordingly and resolve the then() appropriately.

CORS can be used in lieu of event.acceptConnection().

I guess having some primitives for structured clone like behavior would be
nice. That too can be handled by use of Response.blob() and
FileReader[Sync]() on workers, but having primitives means that UAs could
optimize the structured clone behind the scenes instead of actually
creating Blobs.

(Aside: Sometimes I wish we could create a smaller rendering engine that
had no UI and ran exclusively workers and their DOM APIs and make that the
Firefox OS system process)

Nikhil

[Martin Thomson]

> On 2014-12-10, at 11:08, Nikhil Marathe <nsm.n...@gmail.com> wrote:
>
> I guess having some primitives for structured clone like behavior would be
> nice. That too can be handled by use of Response.blob() and
> FileReader[Sync]() on workers, but having primitives means that UAs could
> optimize the structured clone behind the scenes instead of actually
> creating Blobs.

If one side sends an entity body using a Blob or BufferSource and the other side reads it in the same fashion, then we can do a structured clone underneath and avoid HTTP serialisation costs. That’s an optimisation that might not even produce benefits if the data is going cross-process.

[Jonas Sicking]

On Wed, Dec 10, 2014 at 9:46 AM, Ehsan Akhgari <ehsan....@gmail.com> wrote:

> The downside of this approach is of course relying on the service providers
> to get their SWs registered, which may require the user to navigate to the
> service provider's origin, but I suppose that matches the security model of
> the UA prompting for the installation of the service worker, etc.

This seems like a solvable problem.

We could enable website A to hint to the UA that website B has a SW
that would be useful for A to interact with. Then the UA could somehow
give B an opportunity to install a SW.

/ Jonas

[Ehsan Akhgari]

That sounds like a good idea to me.

[jyas...@chromium.org]

"Work with" is a bit too vague here. I think you're suggesting to change which SW cross-origin fetch() calls are routed to. Right now, https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#on-fetch-request-algorithm (called from https://fetch.spec.whatwg.org/#http-fetch) specifies in step 13 that 'fetch' contexts go to the client's SW, not the target URL's SW.

So, what are the implications of changing that? We'd have to ask Anne and Alex, at least, to be sure, but I can think of a couple problems:
1) Sites wouldn't be able to cache cross-origin resources until the other origin installed a SW.
2) Users could more easily write infinite loops between SWs, since at no point would they be guaranteed to bottom out at the network.

We could solve the first with an extra flag to fetch(), letting users explicitly control which origin's SW gets the request, but we can think of navigator.connect() as exactly that flag, followed by some streamlining because of the expected target.

Jeffrey

[Jonas Sicking]

On Wed, Dec 10, 2014 at 12:11 PM, <jyas...@chromium.org> wrote:
> "Work with" is a bit too vague here. I think you're suggesting to change which SW cross-origin fetch() calls are routed to. Right now, https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#on-fetch-request-algorithm (called from https://fetch.spec.whatwg.org/#http-fetch) specifies in step 13 that 'fetch' contexts go to the client's SW, not the target URL's SW.

No, I don't think that's the proposal. As you point out that would
have several problems.

I think instead the proposal is to enable a SW from website A to say
"please consult me for any network requests to https://a.com/apis/*".

Then if website B makes a network request to
https://a.com/apis/whatnot, it would first go to B's SW as per current
SW specifications. But if that SW decides to forward the request to
the network, then rather than directly hitting the network, first go
to A's SW.

Same thing if B's SW for any other reason makes a network request to
https://a.com/apis/whatnot. Rather than directly hitting the network
as is currently defined, we'd first go to A's SW.

/ Jonas

[sligh...@google.com]

Well, that's not entirely clear. Both sites could maintain caches.

> 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.

> We could solve the first with an extra flag to fetch(), letting users explicitly control which origin's SW gets the request, but we can think of navigator.connect() as exactly that flag, followed by some streamlining because of the expected target.

The goal of the navigator.connect() effort is a much more general messaging and services bus. I'm optimistic that we could do something with it that makes many of the nested-fetch use cases both easier for developers to comprehend and better for runtimes to manage. I'm not as optimistic about russian-doll fetch handling and, as we have thus far in SW's design, want to wait until we have a compelling need before going that route.

[Martin Thomson]

On 10/12/14 13:02, sligh...@google.com wrote:
> The goal of the navigator.connect() effort is a much more general
> messaging and services bus.

That sounds considerably more audacious than what I first thought.

> I'm not as optimistic about russian-doll fetch

I don't think that is an accurate characterization of Ehsan's proposal.
Unless further fetches are initiated by the two interceptors, it's
only adding one layer.

[sligh...@google.com]

On Wednesday, December 10, 2014 1:14:11 PM UTC-8, Martin Thomson wrote:
> On 10/12/14 13:02, sligh...@google.com wrote:
> > The goal of the navigator.connect() effort is a much more general
> > messaging and services bus.
>
> That sounds considerably more audacious than what I first thought.

I don't see how it's any more audacious than allowing cross-origin local communication via nested fetch() handlers.

> > I'm not as optimistic about russian-doll fetch
>
> I don't think that is an accurate characterization of Ehsan's proposal.
> Unless further fetches are initiated by the two interceptors, it's
> only adding one layer.

The further-fetches thing is inevitable

[Martin Thomson]

On 10/12/14 13:17, sligh...@google.com wrote:
> The further-fetches thing is inevitable

Not my point. Any message passing system has to solve problems like the
creation of infinite recursion or looping.

The point was just that russian-doll implies something about the
mechanism itself that isn't true. If you make a request, then you get
to intercept it, and so does the origin server. Forward proxy, reverse
proxy.

[Jonas Sicking]

On Wed, Dec 10, 2014 at 1:02 PM, <sligh...@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?

You'd even have the same russian-doll problem since the SW which got
launched when navigator.connect() was called, might in turn use
navigator.connect() to trigger further SWs as far as I can tell?

Generally speaking, it seems like we're talking about a difference in
syntax, not a difference in which SWs or which actors are involved.
But I do agree that the difference in syntax is quite important.

/ Jonas

[Jonas Sicking]

On Wed, Dec 10, 2014 at 4:22 PM, Jonas Sicking <jo...@sicking.cc> wrote:
> On Wed, Dec 10, 2014 at 1:02 PM, <sligh...@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".

Again, there's still an important difference in syntax, which might
accomplish some other goals that you are aiming for?

/ Jonas

[Ehsan Akhgari]

On 2014-12-10 3:32 PM, Jonas Sicking wrote:
> On Wed, Dec 10, 2014 at 12:11 PM, <jyas...@chromium.org> wrote:

>> "Work with" is a bit too vague here. I think you're suggesting to change which SW cross-origin fetch() calls are routed to. Right now, https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#on-fetch-request-algorithm (called from https://fetch.spec.whatwg.org/#http-fetch) specifies in step 13 that 'fetch' contexts go to the client's SW, not the target URL's SW.
>

> No, I don't think that's the proposal. As you point out that would
> have several problems.
>
> I think instead the proposal is to enable a SW from website A to say
> "please consult me for any network requests to https://a.com/apis/*".
>
> Then if website B makes a network request to
> https://a.com/apis/whatnot, it would first go to B's SW as per current
> SW specifications. But if that SW decides to forward the request to
> the network, then rather than directly hitting the network, first go
> to A's SW.
>
> Same thing if B's SW for any other reason makes a network request to
> https://a.com/apis/whatnot. Rather than directly hitting the network
> as is currently defined, we'd first go to A's SW.

Yes, that is exactly what I had in mind.

[Ehsan Akhgari]

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, <sligh...@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.

[Jonas Sicking]

On Wed, Dec 10, 2014 at 6:22 PM, Alex Russell <sligh...@google.com> wrote:

> On Wed, Dec 10, 2014 at 5:48 PM, Ehsan Akhgari <ehsan....@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, <sligh...@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

[Jeffrey Yasskin]

I think we should be really reluctant to add a synchronous interface to an
API that has to communicate cross-process.

Feedback from your Inter-App communication and Web Activities folks would
be really great!

Jeffrey

On Tue, Dec 9, 2014 at 11:04 PM, Jake Leichtling <jleic...@google.com>
wrote:

> As the draft API spec <http://mkruisselbrink.github.io/navigator-connect/> currently
> stands, initial connection and ongoing communication are all asynchronous.
> This is how we have initially envisioned the API, but there isn't any major
> impediment to considering a synchronous piece if a compelling use case
> supports it.
>

> One key part of the API that remains to be sorted out is what will happen
> when a web origin attempts to connect to a Service Worker that is not
> registered. This connection attempt could either fail—perhaps without any
> indication of whether the SW was not installed or rather the connection was
> rejected for some other reason—or it could lead to downloading and
> registering the SW. Maybe this scenario necessitates UI in some cases. This
> is very much an open question.
>
>

> Jake Leichtling | Associate Product Manager ☰ Chrome Apps |
> jleic...@google.com | (415) 279-4508
>
> On Tue, Dec 9, 2014 at 9:34 PM, Bobby Holley <bobby...@gmail.com>
> wrote:
>
>> This API is message-passing only, and doesn't have any synchronous
>> pieces, right?
>>
>> What, from your understanding, are the key/interesting high-level pieces
>> of this API that need to be sorted out?
>>
>> On Tue, Dec 9, 2014 at 9:21 PM, Nikhil Marathe <nsm.n...@gmail.com>

>> wrote:
>>
>>> (cross posted dev.b2g since this seems very relevant to it, but please
>>> keep
>>> the discussion on dev.platform)
>>>
>>> Hi All,
>>>
>>> As part of the ServiceWorker initiative [1], Google is proposing a
>>> `navigator.connect` API [2] to allow cross-origin ServiceWorker
>>> communication. This post is mostly a notice to inform everyone of this
>>> unofficial draft API.
>>>
>>> This seems similar to our Inter-App communication API [3] and I'm sure
>>> the
>>> authors and users of that API have feedback that should be incorporated
>>> in
>>> a cross-web (non-b2g-specific) API. There also seems to be overlap with
>>> some use-cases for Web Activities [4].
>>>
>>> This is a good opportunity for us to influence how cross-origin messaging
>>> is implemented at an early stage. If someone wants to drive this from
>>> Mozilla's side, please "raise your hand".
>>>

[Alex Russell]

On Wed, Dec 10, 2014 at 5:48 PM, Ehsan Akhgari <ehsan....@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, <sligh...@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. 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.

> 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.
>

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.

> 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.
>

My hope is to avoid any changes to existing systems entirely.
Navigator.connect(), as currently formulated, makes no new demands on any
existing (or planned, AFAICT) API.

[David Rajchenbach-Teller]

Isn't that the same issue as Web Activities/Web Intents?

On 10/12/14 20:55, Ehsan Akhgari wrote:
>> This seems like a solvable problem.
>>
>> We could enable website A to hint to the UA that website B has a SW
>> that would be useful for A to interact with. Then the UA could somehow
>> give B an opportunity to install a SW.
>
> That sounds like a good idea to me.
>

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla

[Ehsan Akhgari]

On 2014-12-11 2:03 AM, Jonas Sicking wrote:

> On Wed, Dec 10, 2014 at 6:22 PM, Alex Russell <sligh...@google.com> wrote:
>> On Wed, Dec 10, 2014 at 5:48 PM, Ehsan Akhgari <ehsan....@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, <sligh...@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.

> 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.

[Ehsan Akhgari]

On 2014-12-11 11:12 AM, David Rajchenbach-Teller wrote:
> Isn't that the same issue as Web Activities/Web Intents?

Not really. The use cases around web activities/intents are mostly
around user facing interactions (for example, opening a file in a web
application, or using a web application to send an email/message)
whereas the current proposal is about a client-side programmatic
interface between Web applications. The version of this use case with
the assistance of a server has been around on the Web for a long time
(see the various RESTful APIs published by various web services these
days.) The current service worker spec allows for simple caching of the
results of those API calls without the ability of doing anything
smarter. The current discussion is about full blown communication
between SWs for various websites which will allow them to actually
synthesize a response.

Cheers,
Ehsan

[Ehsan Akhgari]

On 2014-12-11 2:17 PM, Alex Russell wrote:

>
>
> On Thu, Dec 11, 2014 at 11:04 AM, Ehsan Akhgari <ehsan....@gmail.com
> <mailto:ehsan....@gmail.com>> wrote:
>
> On 2014-12-11 2:03 AM, Jonas Sicking wrote:
>
> On Wed, Dec 10, 2014 at 6:22 PM, Alex Russell
> <sligh...@google.com <mailto:sligh...@google.com>> wrote:
>
> On Wed, Dec 10, 2014 at 5:48 PM, Ehsan Akhgari

> <ehsan....@gmail.com <mailto:ehsan....@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,
> <sligh...@google.com

> <mailto:sligh...@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.
>
>
>

> 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

[Anne van Kesteren]

On Wed, Dec 10, 2014 at 6:46 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> So I guess my biggest question so far is: what will we gain by adding
> another API specifically for connecting to the service worker? Do you think
> we can avoid doing that and focus on making XHR/fetch work with cross origin
> SWs?

One idea that has been making the rounds in service worker issues is
having a message channel associated with a request. So when e.g. <img>
does a fetch, we could expose its request as a Request object to the
page. But furthermore, we could also offer a way on that object to
communicate with the service worker's event that is handling the
request, which would allow for adjusting the priority and such, but
could also be seen as a low-level explanation of how responses get
back to the page.

Given that, both API styles discussed here, messaging and fetching,
make some sense to me. I'm not sure we necessarily need to be
exclusive. The latter is nice in that it integrates well with existing
HTTP APIs, the former is nice in that it has a lot more flexibility as
you don't need to follow request/response.


--
https://annevankesteren.nl/

[David Rajchenbach-Teller]

Ok, that makes sense.

I like your proposal.

Cheers,
David

On 11/12/14 20:09, Ehsan Akhgari wrote:
> Not really. The use cases around web activities/intents are mostly
> around user facing interactions (for example, opening a file in a web
> application, or using a web application to send an email/message)
> whereas the current proposal is about a client-side programmatic
> interface between Web applications. The version of this use case with
> the assistance of a server has been around on the Web for a long time
> (see the various RESTful APIs published by various web services these
> days.) The current service worker spec allows for simple caching of the
> results of those API calls without the ability of doing anything
> smarter. The current discussion is about full blown communication
> between SWs for various websites which will allow them to actually
> synthesize a response.
>
> Cheers,
> Ehsan

[Jonas Sicking]

On Thu, Dec 11, 2014 at 11:17 AM, Alex Russell <sligh...@google.com> wrote:
> For the purposes of API composition, either this (or navigator.connect())
> will do.

One thing that we'll need to solve in a lot of the scenarios discussed
in this thread, including navigator.connect(), cross origin SW fetch()
and WebActivities/WebIntents are how to communicate with the SW from a
different origin when the SW from that origin might not be installed
yet.

One solution would be to at that point allow the SW from the other
origin to install itself, which means that you can then just talk to
it as a normal installed SW. However installing a SW could take
significant amount of time. On the order of tens of seconds if the
user is on a slow connection and the SW represent an app with heavy
resources.

So we might need to enable SWs to handle events without first being
installed. Or maybe while they are being installed.

/ Jonas

[Jonas Sicking]

On Thu, Dec 11, 2014 at 5:56 PM, Alex Russell <sligh...@google.com> wrote:
>> One solution would be to at that point allow the SW from the other
>> origin to install itself, which means that you can then just talk to
>> it as a normal installed SW. However installing a SW could take
>> significant amount of time. On the order of tens of seconds if the
>> user is on a slow connection and the SW represent an app with heavy
>> resources.
>

> I'm OK with it taking time. The discovery phase of a n.c() setup is async.

This is along time though. If the initiating website is holding *any*
UX before getting a response you'll end up with a unreasonably bad
experience. So for example if cross-site communication is initiated
when the user press a button, the response to that button push can
take unacceptably long.

It also means that we couldn't use SW for WebActivities/WebIntents for
example. That seems unfortunate.

I don't feel like we're heading down the right design.

/ Jonas

[Alex Russell]

On Thu, Dec 11, 2014 at 11:04 AM, Ehsan Akhgari <ehsan....@gmail.com>

wrote:

> On 2014-12-11 2:03 AM, Jonas Sicking wrote:
>

>> On Wed, Dec 10, 2014 at 6:22 PM, Alex Russell <sligh...@google.com>
>> wrote:

>>
>>> On Wed, Dec 10, 2014 at 5:48 PM, Ehsan Akhgari <ehsan....@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, <sligh...@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.
>>>>>>>
>>>>>>
>>>>>>

For the purposes of API composition, either this (or navigator.connect())
will do.

Both seem entirely unrelated to static routing for resources.

[Alex Russell]

On Thu, Dec 11, 2014 at 3:48 PM, Jonas Sicking <jo...@sicking.cc> wrote:

> On Thu, Dec 11, 2014 at 11:17 AM, Alex Russell <sligh...@google.com>
> wrote:

> > For the purposes of API composition, either this (or navigator.connect())
> > will do.
>

> One thing that we'll need to solve in a lot of the scenarios discussed
> in this thread, including navigator.connect(), cross origin SW fetch()
> and WebActivities/WebIntents are how to communicate with the SW from a
> different origin when the SW from that origin might not be installed
> yet.
>

I sketched out a solution to this problem with Marijn that uses headers
(previously discussed for Service Workers) and I'll update an explainer doc
with that option.

> One solution would be to at that point allow the SW from the other
> origin to install itself, which means that you can then just talk to
> it as a normal installed SW. However installing a SW could take
> significant amount of time. On the order of tens of seconds if the
> user is on a slow connection and the SW represent an app with heavy
> resources.
>

I'm OK with it taking time. The discovery phase of a n.c() setup is async.

> So we might need to enable SWs to handle events without first being
> installed. Or maybe while they are being installed.
>

I don't think that's necessary or advisable.

[Jonas Sicking]

On Mon, Dec 15, 2014 at 2:50 PM, Alex Russell <sligh...@google.com> wrote:
>> So for example if cross-site communication is initiated
>> when the user press a button, the response to that button push can
>> take unacceptably long.
>

> This is, perhaps, a good reason for a discovery system; one layered on top
> of direct point-to-point RPC. It'd be _nice_ to know if you have a local
> handler for some sort of service before you go calling it. The privacy
> implications are pretty thorny, though, so we haven't proposed it.

Yup. I agree with this. Both on the advantages and the disadvantages
with such discoverability.

/ Jonas

[Jonas Sicking]

On Mon, Dec 15, 2014 at 2:50 PM, Alex Russell <sligh...@google.com> wrote:

> On Thu, Dec 11, 2014 at 6:17 PM, Jonas Sicking <jo...@sicking.cc> wrote:

>>
>> On Thu, Dec 11, 2014 at 5:56 PM, Alex Russell <sligh...@google.com>
>> wrote:
>> >> One solution would be to at that point allow the SW from the other
>> >> origin to install itself, which means that you can then just talk to
>> >> it as a normal installed SW. However installing a SW could take
>> >> significant amount of time. On the order of tens of seconds if the
>> >> user is on a slow connection and the SW represent an app with heavy
>> >> resources.
>> >
>> > I'm OK with it taking time. The discovery phase of a n.c() setup is
>> > async.
>>

>> This is along time though.
>

> I don't imagine these are the same SW's as the main app in the common case.
> As a result, these can (should?) be custom built, be lighter, and perhaps
> can communicate with the main app SW (if it's installed). Manually visiting
> these URLs seems, to me, to be about viewing an admin page for a service
> endpoint. So yes, install is at least one network RTT (probably several),
> but I'm not sure that's fatal. At least you can communicate what's going on
> (to the extent that you have UI up and running).

This certainly sounds interesting, but I'm not sure how it fits with
the current registration API. Presumably the SW which handles these
requests (whether they come from a fetch() call or a .connect() call)
would need to be atomically updated with the SW which handles the
website itself. So the SW which handles facebook service calls would
need to be atomically updated with the SW which handles facebook app
UI.

Additionally, SW is currently all about the scope argument. But it's
not clear what scope you would use for a service SW.

I'd definitely be interested to see a proposal which addresses these issues.

/ Jonas

[Alex Russell]

On Thu, Dec 11, 2014 at 6:17 PM, Jonas Sicking <jo...@sicking.cc> wrote:
>
> On Thu, Dec 11, 2014 at 5:56 PM, Alex Russell <sligh...@google.com>
> wrote:
> >> One solution would be to at that point allow the SW from the other
> >> origin to install itself, which means that you can then just talk to
> >> it as a normal installed SW. However installing a SW could take
> >> significant amount of time. On the order of tens of seconds if the
> >> user is on a slow connection and the SW represent an app with heavy
> >> resources.
> >
> > I'm OK with it taking time. The discovery phase of a n.c() setup is
> async.
>
> This is along time though.


I don't imagine these are the same SW's as the main app in the common case.
As a result, these can (should?) be custom built, be lighter, and perhaps
can communicate with the main app SW (if it's installed). Manually visiting
these URLs seems, to me, to be about viewing an admin page for a service
endpoint. So yes, install is at least one network RTT (probably several),
but I'm not sure that's fatal. At least you can communicate what's going on
(to the extent that you have UI up and running).

> If the initiating website is holding *any*
> UX before getting a response you'll end up with a unreasonably bad
> experience.

I think this is a good reason not to transparently tie this to fetch().

> So for example if cross-site communication is initiated
> when the user press a button, the response to that button push can
> take unacceptably long.
>

This is, perhaps, a good reason for a discovery system; one layered on top
of direct point-to-point RPC. It'd be _nice_ to know if you have a local
handler for some sort of service before you go calling it. The privacy
implications are pretty thorny, though, so we haven't proposed it.

> It also means that we couldn't use SW for WebActivities/WebIntents for
> example. That seems unfortunate.
>

I don't follow.

[Jonas Sicking]

On Tue, Dec 16, 2014 at 11:00 AM, Alex Russell <sligh...@google.com> wrote:
> On Mon, Dec 15, 2014 at 6:25 PM, Jonas Sicking <jo...@sicking.cc> wrote:
>>
>> On Mon, Dec 15, 2014 at 2:50 PM, Alex Russell <sligh...@google.com>

>> This certainly sounds interesting, but I'm not sure how it fits with
>> the current registration API. Presumably the SW which handles these
>> requests (whether they come from a fetch() call or a .connect() call)
>> would need to be atomically updated with the SW which handles the
>> website itself. So the SW which handles facebook service calls would
>> need to be atomically updated with the SW which handles facebook app
>> UI.
>>
>> Additionally, SW is currently all about the scope argument. But it's
>> not clear what scope you would use for a service SW.
>
>

> I think you'd want to have a scope like:
>
> https://example.com/services/name/v1/
>
> As the scope for a SW hosted at:
>
> https://example.com/services/name/v1/service.js

I'm not sure I understand. This seems like a new way to interpret SW
scopes? How do these URLs relate to .connect()? Are these real URLs
that actually are fetched over the network apart from the SW script
itself?

FWIW, I think this shows that basing SW registration entirely on
scopes for pages that it serves is causing problems for other uses of

SW.

>> I'd definitely be interested to see a proposal which addresses these
>> issues.
>
>

> We've been chatting about this and it feels like there's a pretty big design
> space that includes permutations of:
>
> postMessage/ports to/from a local SW
> a look-aside fetch() that is "local only", e.g. doesn't go to the network if
> there isn't an existing SW to handle it
> a look-aside fetch() that could fault to the network if it isn't locally
> handled
>
> They don't seem exclusive, either. We could imagine making more than one of
> them available.

Agreed.

> There's also an independent choice about the question of installation via
> headers.
>
> We're gonna write these up because it feels like it'd be useful to have some
> common understanding of the design alternatives.

Looking forward to that.

> It ALSO seems like we should get together and talk with higher bandwidth.
> Perhaps some F2F time in January would be useful? Is that possible?

I can't speak for others, but I'll be in SF in January.

/ Jonas

[Dave Huseby]

How does this differ from window.postMessage? I thought postMessage was
going to be the main way that we did cross-origin communication between
apps and service workers?

The fxos security team has been discussing ideas for how crypto-hardware
(e.g. secure elements, TPM, etc) vendors could expose their hardware to
web apps in a somewhat generic way. One idea was to have
vendor-supplied SW that presented an API via cross-origin message
passing. The SW translates API call messages into APDU's that get sent
to the hardware and returns the results. I think we were assuming that
the main message passing mechanism would be postMessage. It sounds to
me like fetch()/navigator.connect() is more network/offline resource
oriented and would be a better fit for what we are thinking.

--dave

[Dave Huseby]

[Alex Russell]

> I'd definitely be interested to see a proposal which addresses these
> issues.
>

We've been chatting about this and it feels like there's a pretty big
design space that includes permutations of:

- postMessage/ports to/from a local SW
- a look-aside fetch() that is "local only", e.g. doesn't go to the

network if there isn't an existing SW to handle it

- a look-aside fetch() that could fault to the network if it isn't

locally handled

They don't seem exclusive, either. We could imagine making more than one of
them available.

There's also an independent choice about the question of installation via
headers.

We're gonna write these up because it feels like it'd be useful to have
some common understanding of the design alternatives.

It ALSO seems like we should get together and talk with higher bandwidth.
Perhaps some F2F time in January would be useful? Is that possible?

Regards

[Jake Leichtling]

Hope everyone had a great holiday season.

I'd like to propose that we meet up either next week or the week after to discuss in person. Location TBD, but likely to be in/near Mozilla's/Google's SF office (we're at 345 Spear Street).

I've created a Doodle to help us coordinate: http://doodle.com/p926r9eemyfazv6g#table

[kenji...@chromium.org]

I would love to see something like this.

Third party services (e.g. Analytics, Fonts, Social) should be able to declare that they have a Service Worker that will happily take care of the requests that are relevant for them if the current site's SW (if any) let them through.

Failing that, we might see a proliferation of sites that go through the trouble of offlining these third party services themselves in their quest of nailing their own offline-first user experience. For Fonts, we'll loose on cache hit opportunities since that site's SW will most likely put them in its same-origin restricted Cache.


Also, letting these third party services take matters into their own hands opens up interesting opportunities.

For instance, a Fonts service provider might want to use the background sync API to regularly rationalize its Fonts cache:
- pruning infrequently used fonts
- prefetching popular fonts for a given market
- fetching the whole font after seeing several requests for bits of it via dynamic subtyping or unicode-range (e.g. CJK fonts can be quite huge)
- mapping subset requests to the whole font there after

---
I think these use cases lead to the following requirements:

1. The third party service is able to tell the UA to install and optionally activate right away its service worker from the client site

Naive strawman: the client site added a script tag pointing to the third party's bootstrap JavaScript; the boostrap Javascript code calls navigator.connect(url of third party's SW, {takeControl: true/(default:false)})

UA installs the SW if needed.
takeControl: true would activate the SW right away



2. The third party service is able to tell the UA that its SW is happy to take care of in-scope requests that the client site's SW (if any) has decided to let go through.

Naive strawman: an extra parameter (consulted... ahem, couldn't think of anything better...) => navigator.connect(url of third party's SW, {consulted: true})


3. The third party service is able to tell the UA that its SW is happy to take care of in-scope requests that any client site didn't deal with (via a SW).

I *think* this is needed for the Fonts service use case where relevant requests [1] might trigger before the third party bootstrap script has a chance to run.

Naively, a previous call to navigator.connect(url, {consulted: true}) would make that happen by default but I'm probably missing something important that makes this a bad idea.


[1]: The link rel to the CSS containing the @font-face definition [a] and perhaps the font itself (if consensus is reached on [b])
[a]: https://developers.google.com/fonts/docs/getting_started
[b]: http://lists.w3.org/Archives/Public/www-style/2014Nov/0593.html


PS: I'll try to join the F2F via VC if possible.

[Ehsan Akhgari]

On 2015-01-07 3:34 AM, kenji...@chromium.org wrote:
>
> On Thursday, December 11, 2014 10:45:26 AM UTC+9, Ehsan Akhgari wrote:
>> On 2014-12-10 3:32 PM, Jonas Sicking wrote:
>>>
>>> I think instead the proposal is to enable a SW from website A to say
>>> "please consult me for any network requests to https://a.com/apis/*".
>>>
>>> Then if website B makes a network request to
>>> https://a.com/apis/whatnot, it would first go to B's SW as per current
>>> SW specifications. But if that SW decides to forward the request to
>>> the network, then rather than directly hitting the network, first go
>>> to A's SW.
>>>
>>> Same thing if B's SW for any other reason makes a network request to
>>> https://a.com/apis/whatnot. Rather than directly hitting the network
>>> as is currently defined, we'd first go to A's SW.
>>
>> Yes, that is exactly what I had in mind.
>
>
> I would love to see something like this.

I'm happy to hear someone inside Google is interested in this as well!

> Third party services (e.g. Analytics, Fonts, Social) should be able to declare that they have a Service Worker that will happily take care of the requests that are relevant for them if the current site's SW (if any) let them through.
>
> Failing that, we might see a proliferation of sites that go through the trouble of offlining these third party services themselves in their quest of nailing their own offline-first user experience. For Fonts, we'll loose on cache hit opportunities since that site's SW will most likely put them in its same-origin restricted Cache.
>
>
> Also, letting these third party services take matters into their own hands opens up interesting opportunities.
>
> For instance, a Fonts service provider might want to use the background sync API to regularly rationalize its Fonts cache:
> - pruning infrequently used fonts
> - prefetching popular fonts for a given market
> - fetching the whole font after seeing several requests for bits of it via dynamic subtyping or unicode-range (e.g. CJK fonts can be quite huge)
> - mapping subset requests to the whole font there after

Agreed.

> I think these use cases lead to the following requirements:
>
> 1. The third party service is able to tell the UA to install and optionally activate right away its service worker from the client site
>
> Naive strawman: the client site added a script tag pointing to the third party's bootstrap JavaScript; the boostrap Javascript code calls navigator.connect(url of third party's SW, {takeControl: true/(default:false)})
>
> UA installs the SW if needed.
> takeControl: true would activate the SW right away

I thought that navigator.connect() as envisioned by
<https://github.com/mkruisselbrink/navigator-connect> is about letting
websites communicate to SWs, not let them register one. It seems like
#1 above is about registration. Is there any reason to not extend the
existing SW registration mechanism?

> 2. The third party service is able to tell the UA that its SW is happy to take care of in-scope requests that the client site's SW (if any) has decided to let go through.
>
> Naive strawman: an extra parameter (consulted... ahem, couldn't think of anything better...) => navigator.connect(url of third party's SW, {consulted: true})

I'd argue that when the SW for site A lets a request for site B to go to
the network, we should consult B's SW (or a special cross-origin
handling SW from B) if one is present before going to the network by
default.

> 3. The third party service is able to tell the UA that its SW is happy to take care of in-scope requests that any client site didn't deal with (via a SW).

Isn't this the same thing as #1?

> I *think* this is needed for the Fonts service use case where relevant requests [1] might trigger before the third party bootstrap script has a chance to run.

Well, we only have this problem if the embedding website triggers the
registration as well. I think we can avoid the issue if we let that
website handle its own registration in the normal way.

> Naively, a previous call to navigator.connect(url, {consulted: true}) would make that happen by default but I'm probably missing something important that makes this a bad idea.

I'm still struggling to understand what exactly navigator.connect() as
proposed does. :-)

Cheers,
Ehsan