Open annevk opened 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.
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.
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.
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) ...
}
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.