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

Fwd: [b2g] Improve performance on multi-core device

Forward this mail to dev-platform to hopefully get more feedbacks, sorry for the extra mail. Ting - Forwarded Message - From: "Ting-Yu Chou" To: "dev-b2g" Sent: Tuesday, November 11, 2014 7:02:29 PM Subject: [b2g] Improve performance on multi-core device Hello, We opened bug 1093564 t

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

You can now test mozharness changes on try

Re-sending due to bug https://bugzilla.mozilla.org/show_bug.cgi?id=1108698 My apologies if you're getting this many times! tl; dr; if you want to test mozharness changes on try you can do so by modifying testing/mozharness/mozharness.json [1] and pointing it to your own repository. This currently

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

Web APIs documentation meeting this Friday, December 12 at 10 AM PST

The Web APIs documentation meeting is Friday at 10 AM Pacific Time (see http://bit.ly/APIdocsMDN for your time zone). Everyone's welcome to attend; if you're interested in ensuring that all Web APIs are properly documented, we'd love your input. We have an agenda, as well as details on how to

Re: Capturing additional metadata in moz.build files

On 12/10/14 9:48 AM, Ehsan Akhgari wrote: On 2014-12-10 12:30 PM, Benoit Girard wrote: On Tue, Dec 9, 2014 at 1:46 PM, Gregory Szorc wrote: * Building a subscription service for watching code and reviews They all sound great. Except I'm not sure what you mean by this one. Are you suggesti

Re: Capturing additional metadata in moz.build files

On 12/9/14 7:46 PM, Gregory Szorc wrote: > * Building a subscription service for watching code and reviews I think this would be quite interesting, but I'm also not quite sure what metadata you would put into the files. In the past I've built a small script that uses mozilla pulse to figure out w

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: Capturing additional metadata in moz.build files

On 2014-12-10 12:30 PM, Benoit Girard wrote: On Tue, Dec 9, 2014 at 1:46 PM, Gregory Szorc wrote: * Building a subscription service for watching code and reviews They all sound great. Except I'm not sure what you mean by this one. Are you suggesting that we have something like a list of em

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: Capturing additional metadata in moz.build files

On Tue, Dec 9, 2014 at 1:46 PM, Gregory Szorc wrote: > * Building a subscription service for watching code and reviews > They all sound great. Except I'm not sure what you mean by this one. Are you suggesting that we have something like a list of email in moz.build to register for updates to a

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