mkruisselbrink / navigator-connect

Apache License 2.0
25 stars 8 forks source link

Ports #26

Open annevk opened 9 years ago

annevk commented 9 years ago

We avoided ports in service workers for their postMessage() design. It's not clear what they bring to the table here that we couldn't achieve via other means.

jungkees commented 9 years ago

Yeah right. We tried to avoid passing ports around in service worker's messaging to keep the API simple. But the service worker's messaging model is between the service worker and its (potential) controllee in the same-origin while n.c()'s messaging is between a non-controlled-client and a rather loosely-coupled off-origin service worker. That's just a fact. Actually, it's hard to expect at this stage what the best design will be like. I think we can start the iteration on the current proposal while opening other possibilities.

annevk commented 9 years ago

A client that messages a service worker is not necessarily controlled by it. Nor is a client messaged by the service worker necessarily controlled. There's obviously a couple of differences with cross-origin service workers, but it's not clear to me why a new messaging strategy is needed.

jungkees commented 9 years ago

A client that messages a service worker is not necessarily controlled by it. Nor is a client messaged by the service worker necessarily controlled.

That's true, but their relationship is a service worker and its (potential) controllee within a single origin.

There's obviously a couple of differences with cross-origin service workers, but it's not clear to me why a new messaging strategy is needed.

As of now, I cannot clearly come up with a model where service worker's Client also represents a n.c()'s client and a service worker's global provides any match API to get the n.c() clients with any filtering criteria. Currently, what's clear is a client tries to connect, the service either accepts or rejects, and the connected client and service thereby do the channel-messaging like communication. But yeah.. we should consider all the possibilities based on the use cases we get.

jakearchibald commented 9 years ago

I guess we could use the existing messaging system if receiving cross-origin messages was opt-in.

getCrossOriginServiceWorkerSomehow().then(sw => sw.postMessage("Hey!"));

And in the other SW:

optIntoCrossOriginMessagesSomehow();

self.onmessage = event => {
  if (event.origin != location.origin) ...
}