Intent to Implement: navigator.connect

[Marijn Kruisselbrink]

Contact emails

m...@chromium.org

Spec

Unofficial draft spec: http://mkruisselbrink.github.io/navigator-connect/

Some more background in this document.

Summary

Allow cross-domain postMessage to a Service Worker.

Motivation

Web developers can communicate cross-domain on the client (for example, while the user is offline) using iframes and postMessage (although this isn’t possible from a worker context). Let's simplify this and let a page communicate with another site's Service Worker directly using postMessage.

Compatibility Risk

+ This brand-new feature this is unlikely to break compatibility with existing web content.

+ The API is small: A new method on navigator. The rest is cobbled together out of MessagePorts.

+ If we shipped this feature but regretted it, the API can simply start rejecting the Promise it hands out during the deprecation period. Reasonable use of the API should handle rejection, because the user may not have a Service Worker installed for a particular site anyway.

+ Most of the spec can be polyfilled on top of the existing cross origin iframes and postMessage support (the part that can’t be polyfilled is worker-to-worker communication).

- This feature depends on Service Worker, so cross-browser compatibility will be limited to the degree that browsers implement Service Worker. Mozilla and Chromium are implementing Service Worker currently.

- We haven't taken the temperature of other browser vendors yet.

Ongoing technical constraints

This depends on Service Worker, and might need some small changes to the MessagePort handling code in Chrome.

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes.

OWP launch tracking bug?

There isn’t one (there is http://crbug.com/426458, but that isn’t an OWP launch tracking bug).

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5709330426888192

Requesting approval to ship?

No. This will be implemented behind a runtime enabled feature to get feedback from web developers to inform the standards process.

[Alex Russell]

I'm hugely excited about this!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Elliott Sprehn]

Where is the standards discussion of this? Has it been sent to public-webapps or whatwg yet?

On Fri, Nov 7, 2014 at 4:43 PM, Marijn Kruisselbrink <m...@chromium.org> wrote:

[Jochen Eisinger]

Who is going to work on this? I would rather see more than one engineer working on this, maybe somebody from the service worker team that also is experienced with cross process messaging and security?

I agree that we should start a standards discussion about this rather sooner than later.

best

-jochen

[Darin Fisher]

I believe the idea of navigator.connect has been getting socialized. I'm not sure to what extent that has happened on standards lists. slightlyoff@ has been championing the idea.

On the implementation side, there are actually several efforts in flight that are connected to this. The work underway to integrate Mojo IPC in Chromium is a part of the story.

morrita@ has been working on replacing the implementation of IPC::Channel with one that sits on top of a Mojo MessagePipeHandle. This will allow us to re-implement HTML5 MessagePort in terms of MessagePipeHandle. (We'll be able to pass Mojo handles over normal Chrome IPC.)

There are some benefits of using Mojo IPC here: 1) there's energy being spent on making it work better, so we benefit from that, 2) it becomes easy to leverage Mojo messaging format and Mojo on the service implementation side. #2 is totally optional, but an origin might choose to use it. It might also be useful in the context of extensions to expose new extension APIs using navigator.connect rather than via traditional methods. There are other applications too.

haraken@ and I also discussed how we can leverage navigator.connect as part of the blink-in-js work. Once we migrate blink into the chromium repository, it should be possible to replace blink API that supports blink modules w/ navigator.connect by leveraging Mojo (e.g., defining service interfaces using the mojom language and JS bindings generator).

-Darin

[Marijn Kruisselbrink]

On Fri, Nov 7, 2014 at 6:11 PM, Elliott Sprehn <esp...@chromium.org> wrote:

Where is the standards discussion of this? Has it been sent to public-webapps or whatwg yet?

As I mentioned in the "Compatibility Risk" section there hasn't been any standards discussion of this yet in the w3c or whatwg. The API has been discussed with various interested parties both inside and outside of google, but the next step of course is indeed to discuss this more formally in a standards body (I'm not sure if that should be whatwg or public-webapps?) Of course I wouldn't hope to ship anything like this before at least a reasonable level of consensus on the spec has been reached.

[Marijn Kruisselbrink]

On Sun, Nov 9, 2014 at 1:09 PM, Jochen Eisinger <joc...@chromium.org> wrote:

Who is going to work on this? I would rather see more than one engineer working on this, maybe somebody from the service worker team that also is experienced with cross process messaging and security?

This is a project that is being worked on more or less collaboratively by the fizz team and service worker teams. The service worker team currently doesn't have the manpower to fully dedicate to navigator.connect, which is why this ended up with the fizz team. I'm trying to push forward with this since nobody else had time to dedicate to it and I feel it is an important feature to have, but of course I won't be able to do that without some help from the people that know the messaging code better than I do.

 

I agree that we should start a standards discussion about this rather sooner than later.

Completely agree with this as well. Although I don't think we need to entirely block (investigating) implementing some form of cross origin service worker communication on fully working out what the web facing API of such a feature would look like.

[rek...@gmail.com]

I presume ya'll actually want to accept input or comment in some way about this thing you are implementing? This is intended at some point in some manner towards standardization? But you're going to implement it first? Does that mean comments are or aren't welcome while that happens? The safe word is still IndexedDB right? IndexedDB! IndexedDB!

Your API looks really good. Really really good. Awesome. This API as here is as it should be. I too am hugely excited about this.

I do want Discovery though. I'll try to find some spare time to write up a spec and to implement a polyfill.

https://github.com/mkruisselbrink/navigator-connect/issues/1

Without discovery we have to know ahead of time who we'd want to connect to. We'd need signalling to give us URL's to try. With discovery, the user agent can internally signal peer availability within itself.

[rek...@gmail.com]

Was https://docs.google.com/document/d/16iX4Tj4i0dL6CRnLYx3ekLQ5h2GVPDWuAClsI9CLg04/edit in circulation beyond Google before @mek's posting here? Has it been circulated in a public fashion before?

Is there any pertinent working group that Chromium might think appropriate for this standard to be used in? Are any other members of that standard group aware of any of this work?