Re: Cross origin communication and the navigator.connect API

On 2015-01-07 3:34 AM, kenjibah...@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:/

Re: Cross origin communication and the navigator.connect API

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 mak

Re: Cross origin communication and the navigator.connect API

On Mon, Dec 15, 2014 at 6:25 PM, Jonas Sicking wrote: > On Mon, Dec 15, 2014 at 2:50 PM, Alex Russell > wrote: > > On Thu, Dec 11, 2014 at 6:17 PM, Jonas Sicking wrote: > >> > >> On Thu, Dec 11, 2014 at 5:56 PM, Alex Russell > >> wrote: > >> >> One solution would be to at that point allow the

Re: Cross origin communication and the navigator.connect API

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

Re: Cross origin communication and the navigator.connect API

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

Re: Cross origin communication and the navigator.connect API

On Tue, Dec 16, 2014 at 11:00 AM, Alex Russell wrote: > On Mon, Dec 15, 2014 at 6:25 PM, Jonas Sicking wrote: >> >> On Mon, Dec 15, 2014 at 2:50 PM, Alex Russell >> wrote: >> > On Thu, Dec 11, 2014 at 6:17 PM, Jonas Sicking wrote: >> >> >> >> On Thu, Dec 11, 2014 at 5:56 PM, Alex Russell >> >>

Re: Cross origin communication and the navigator.connect API

On Thu, Dec 11, 2014 at 6:17 PM, Jonas Sicking wrote: > > On Thu, Dec 11, 2014 at 5:56 PM, Alex Russell > 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. Howe

Re: Cross origin communication and the navigator.connect API

On Mon, Dec 15, 2014 at 2:50 PM, Alex Russell wrote: > On Thu, Dec 11, 2014 at 6:17 PM, Jonas Sicking wrote: >> >> On Thu, Dec 11, 2014 at 5:56 PM, Alex Russell >> wrote: >> >> One solution would be to at that point allow the SW from the other >> >> origin to install itself, which means that you

Re: Cross origin communication and the navigator.connect API

On Mon, Dec 15, 2014 at 2:50 PM, Alex Russell 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 direc

Re: Cross origin communication and the navigator.connect API

On Thu, Dec 11, 2014 at 3:48 PM, Jonas Sicking wrote: > On Thu, Dec 11, 2014 at 11:17 AM, Alex Russell > 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,

Re: Cross origin communication and the navigator.connect API

On Thu, Dec 11, 2014 at 11:04 AM, Ehsan Akhgari wrote: > On 2014-12-11 2:03 AM, Jonas Sicking wrote: > >> On Wed, Dec 10, 2014 at 6:22 PM, Alex Russell >> wrote: >> >>> On Wed, Dec 10, 2014 at 5:48 PM, Ehsan Akhgari >>> wrote: >>> On 2014-12-10 7:45 PM, Jonas Sicking wrote: >

Re: Cross origin communication and the navigator.connect API

On Thu, Dec 11, 2014 at 5:56 PM, Alex Russell 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 th

Re: Cross origin communication and the navigator.connect API

On Thu, Dec 11, 2014 at 11:17 AM, Alex Russell 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 WebActivit

Re: Cross origin communication and the navigator.connect API

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 em

Re: Cross origin communication and the navigator.connect API

On Wed, Dec 10, 2014 at 6:46 PM, Ehsan Akhgari 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 id

Re: Cross origin communication and the navigator.connect API

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

Re: Cross origin communication and the navigator.connect API

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

Re: Cross origin communication and the navigator.connect API

On 2014-12-11 2:03 AM, Jonas Sicking wrote: On Wed, Dec 10, 2014 at 6:22 PM, Alex Russell wrote: On Wed, Dec 10, 2014 at 5:48 PM, Ehsan Akhgari wrote: On 2014-12-10 7:45 PM, Jonas Sicking wrote: On Wed, Dec 10, 2014 at 4:22 PM, Jonas Sicking wrote: On Wed, Dec 10, 2014 at 1:02 PM, wro

Re: Cross origin communication and the navigator.connect API

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 o

Re: Cross origin communication and the navigator.connect API

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 wrote: > As the draft API sp

Re: Cross origin communication and the navigator.connect API

On Wed, Dec 10, 2014 at 6:22 PM, Alex Russell wrote: > On Wed, Dec 10, 2014 at 5:48 PM, Ehsan Akhgari > wrote: >> >> On 2014-12-10 7:45 PM, Jonas Sicking wrote: >>> >>> On Wed, Dec 10, 2014 at 4:22 PM, Jonas Sicking wrote: On Wed, Dec 10, 2014 at 1:02 PM, wrote: >> >> 2) User

Re: Cross origin communication and the navigator.connect API

On 2014-12-10 7:45 PM, Jonas Sicking wrote: On Wed, Dec 10, 2014 at 4:22 PM, Jonas Sicking wrote: On Wed, Dec 10, 2014 at 1:02 PM, 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

Re: Cross origin communication and the navigator.connect API

On 2014-12-10 3:32 PM, Jonas Sicking wrote: On Wed, Dec 10, 2014 at 12:11 PM, 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-fetc

Re: Cross origin communication and the navigator.connect API

On Wed, Dec 10, 2014 at 4:22 PM, Jonas Sicking wrote: > On Wed, Dec 10, 2014 at 1:02 PM, 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

Re: Cross origin communication and the navigator.connect API

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

Re: Cross origin communication and the navigator.connect API

On 10/12/14 13:17, slightly...@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

Re: Cross origin communication and the navigator.connect API

On Wednesday, December 10, 2014 1:14:11 PM UTC-8, Martin Thomson wrote: > On 10/12/14 13:02, slightly...@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

Re: Cross origin communication and the navigator.connect API

On 10/12/14 13:02, slightly...@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

Re: Cross origin communication and the navigator.connect API

On Wednesday, December 10, 2014 12:11:39 PM UTC-8, jyas...@chromium.org wrote: > On Wednesday, December 10, 2014 9:46:58 AM UTC-8, Ehsan Akhgari wrote: > > On 2014-12-10 12:21 AM, Nikhil Marathe wrote: > > > (cross posted dev.b2g since this seems very relevant to it, but please > > > keep > > > th

Re: Cross origin communication and the navigator.connect API

On Wed, Dec 10, 2014 at 12:11 PM, 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

Re: Cross origin communication and the navigator.connect API

On Wednesday, December 10, 2014 9:46:58 AM UTC-8, Ehsan Akhgari wrote: > 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

Re: Cross origin communication and the navigator.connect API

On 2014-12-10 2:46 PM, Jonas Sicking wrote: On Wed, Dec 10, 2014 at 9:46 AM, Ehsan Akhgari 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

Re: Cross origin communication and the navigator.connect API

On Wed, Dec 10, 2014 at 9:46 AM, Ehsan Akhgari 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 pr

Re: Cross origin communication and the navigator.connect API

> On 2014-12-10, at 11:08, Nikhil Marathe 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 clon

Re: Cross origin communication and the navigator.connect API

On Wed, Dec 10, 2014 at 9:46 AM, Ehsan Akhgari wrote: > 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 p

Re: Cross origin communication and the navigator.connect API

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. ___ dev-platform mailing list dev-platf

Re: Cross origin communication and the navigator.connect API

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 co

Re: Cross origin communication and the navigator.connect API

On Tue, Dec 9, 2014 at 11:04 PM, Jake Leichtling wrote: > As the draft API spec > currently > stands, initial connection and ongoing communication are all asynchronous. > This is how we have initially envisioned the API, but there isn't any ma

Re: Cross origin communication and the navigator.connect API

As the draft API spec 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 u

Re: Cross origin communication and the navigator.connect API

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 wrote: > (cross posted dev.b2g since this seems very