Re: Cross origin communication and the navigator.connect API
As the draft API spec http://mkruisselbrink.github.io/navigator-connect/ 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 use case supports it. One key part of the API that remains to be sorted out is what will happen when a web origin attempts to connect to a Service Worker that is not registered. This connection attempt could either fail—perhaps without any indication of whether the SW was not installed or rather the connection was rejected for some other reason—or it could lead to downloading and registering the SW. Maybe this scenario necessitates UI in some cases. This is very much an open question. Jake Leichtling | Associate Product Manager ☰ Chrome Apps | jleichtl...@google.com | (415) 279-4508 On Tue, Dec 9, 2014 at 9:34 PM, Bobby Holley bobbyhol...@gmail.com wrote: 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 nsm.nik...@gmail.com 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 communication. This post is mostly a notice to inform everyone of this unofficial draft API. This seems similar to our Inter-App communication API [3] and I'm sure the authors and users of that API have feedback that should be incorporated in a cross-web (non-b2g-specific) API. There also seems to be overlap with some use-cases for Web Activities [4]. This is a good opportunity for us to influence how cross-origin messaging is implemented at an early stage. If someone wants to drive this from Mozilla's side, please raise your hand. Best, Nikhil [1]: https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html [2]: https://github.com/mkruisselbrink/navigator-connect [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=876397 [4]: https://developer.mozilla.org/en-US/docs/Web/API/Web_Activities ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cross origin communication and the navigator.connect API
On Tue, Dec 9, 2014 at 11:04 PM, Jake Leichtling jleichtl...@google.com wrote: As the draft API spec http://mkruisselbrink.github.io/navigator-connect/ 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 use case supports it. Synchronous pieces are basically a non-starter IMO, which is why I wanted to double-check that this was async. One key part of the API that remains to be sorted out is what will happen when a web origin attempts to connect to a Service Worker that is not registered. This connection attempt could either fail—perhaps without any indication of whether the SW was not installed or rather the connection was rejected for some other reason—or it could lead to downloading and registering the SW. Maybe this scenario necessitates UI in some cases. This is very much an open question. Ok. That kind of stuff isn't really my domain, so somebody else on the Mozilla side should pick this up. Overholt - if nobody jumps on this, can you follow up and make sure that we make an explicit decision about what to do here? Cheers, bholley ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Capturing additional metadata in moz.build files
On Tue, Dec 9, 2014 at 1:46 PM, Gregory Szorc g...@mozilla.com 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 component? I'm not sure I'd like to see people committing to the tree to register/CC themselves. But maybe you had something else in mind? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 communication. This post is mostly a notice to inform everyone of this unofficial draft API. This seems similar to our Inter-App communication API [3] and I'm sure the authors and users of that API have feedback that should be incorporated in a cross-web (non-b2g-specific) API. There also seems to be overlap with some use-cases for Web Activities [4]. This is a good opportunity for us to influence how cross-origin messaging is implemented at an early stage. If someone wants to drive this from Mozilla's side, please raise your hand. I am very interested in this problem, and in fact I've been thinking about what we should do for cross origin SW communications for a while. :-) I do support the idea but I'm not convinced that we need a specific API to talk to the SW (such as navigator.connect.) What I have been envisioning is allowing SWs that are registered with the UA to respond to cross origin fetch requests made through XHR/fetch even from documents that are themselves not controlled by a SW. The reasoning I have for this is as follows: Currently on the Web, the defacto way that applications talk to each other cross origin is through XHR using CORS. See the numerous HTTP based APIs that are developed by various organizations that are used by Web applications right now. With service workers, we are going to have a Web that is usable off-line, and we can also use SWs to do things such as smarter caching on the client side. The next interesting use case would be to enable the usage of these HTTP based APIs offline (or doing smart caching on the client side, etc.) I see no great reason to require Web applications to write specific code for this, though. Let's say that my application XHRs into https://socialnetwork.com/get/friends in order to get the user's list of friends. It would be nice to allow that request to be handled by the service worker registered for socialnetwork.com and give that SW control over whether it wants to respond to the request without going to the network. This has the additional advantage that people's code and all of the ecosystem that they have built on top of XHR based APIs over the years will just work offline once the service providers get their SWs registered. 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 prompting for the installation of the service worker, etc. 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? Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 g...@mozilla.com 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 component? I'm not sure I'd like to see people committing to the tree to register/CC themselves. Yeah, I hope that is not what's being suggested here either! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 when a commit changes the UUID of an IDL file or a such file is added or deleted. I had a lot of ideas on how this could be built into a real service, that allows the core or addon developer to better watch if changes to the tree could affect his or her own code. Maybe this would be interesting to a larger group of people, resulting in a such service to watch code. I also thought it would be pretty cool for Thunderbird (or other apps, for that matter) to use the static analysis data from DXR to determine the chance of toolkit code changes requiring changes in Thunderbird. I never looked into this though. Sorry if I am off topic, I just thought I'd throw my ideas out there in case a code watching service becomes real. Philipp ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 g...@mozilla.com 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 component? I'm not sure I'd like to see people committing to the tree to register/CC themselves. Yeah, I hope that is not what's being suggested here either! Subscription would not be in tree. Instead, metadata about grouping and labels for files/directories/modules would be in the tree to make subscriptions easier to manage. And even then I'm not convinced that is much better than just letting people manage their own filters. I wanted an extra bullet point, OK :) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 join, here: https://etherpad.mozilla.org/WebAPI-docs-2014-12-12 . If you have topics you wish to discuss, please feel free to add them to the agenda. We look forward to seeing you there! If you're unable to attend but have been working on documentation related to APIs, please add notes to the agenda about what you've been doing so we can share your progress. Eric Shepherd Developer Documentation Lead Mozilla http://www.bitstampede.com/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cross origin communication and the navigator.connect API
On Wed, Dec 10, 2014 at 9:46 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
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 proposing a
`navigator.connect` API [2] to allow cross-origin ServiceWorker
communication. This post is mostly a notice to inform everyone of this
unofficial draft API.
This seems similar to our Inter-App communication API [3] and I'm sure the
authors and users of that API have feedback that should be incorporated in
a cross-web (non-b2g-specific) API. There also seems to be overlap with
some use-cases for Web Activities [4].
This is a good opportunity for us to influence how cross-origin messaging
is implemented at an early stage. If someone wants to drive this from
Mozilla's side, please raise your hand.
I am very interested in this problem, and in fact I've been thinking about
what we should do for cross origin SW communications for a while. :-) I
do support the idea but I'm not convinced that we need a specific API to
talk to the SW (such as navigator.connect.)
What I have been envisioning is allowing SWs that are registered with the
UA to respond to cross origin fetch requests made through XHR/fetch even
from documents that are themselves not controlled by a SW. The reasoning I
have for this is as follows:
Currently on the Web, the defacto way that applications talk to each other
cross origin is through XHR using CORS. See the numerous HTTP based APIs
that are developed by various organizations that are used by Web
applications right now. With service workers, we are going to have a Web
that is usable off-line, and we can also use SWs to do things such as
smarter caching on the client side. The next interesting use case would be
to enable the usage of these HTTP based APIs offline (or doing smart
caching on the client side, etc.)
I see no great reason to require Web applications to write specific code
for this, though. Let's say that my application XHRs into
https://socialnetwork.com/get/friends in order to get the user's list of
friends. It would be nice to allow that request to be handled by the
service worker registered for socialnetwork.com and give that SW control
over whether it wants to respond to the request without going to the
network. This has the additional advantage that people's code and all of
the ecosystem that they have built on top of XHR based APIs over the years
will just work offline once the service providers get their SWs registered.
I like this idea. It would even be possible to create some lib that used a
bit of JS reflection to auto create fully RESTful APIs from the functions
exposed to cross-origin in the SW script. But I'm getting ahead of myself :)
The fetch() based API won't be as user friendly as postMessage() for
gossiping (where the two SWs are having an entire conversation rather than
just a couple of exchanges), but it should be easy to abstract that away
into a library too so that:
var ipc = new LibIPC('//foo.com')
ipc.send(/addToCart, itemid=4).send(/useCachedCredentialsToPay,
authToken=baz).then(function() {}, function() {})
and underneath the lib would chain calls to fetch() and deal with response
Promises accordingly and resolve the then() appropriately.
CORS can be used in lieu of event.acceptConnection().
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 clone behind the scenes instead of actually
creating Blobs.
(Aside: Sometimes I wish we could create a smaller rendering engine that
had no UI and ran exclusively workers and their DOM APIs and make that the
Firefox OS system process)
Nikhil
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Cross origin communication and the navigator.connect API
On 2014-12-10, at 11:08, Nikhil Marathe nsm.nik...@gmail.com 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 clone behind the scenes instead of actually creating Blobs. If one side sends an entity body using a Blob or BufferSource and the other side reads it in the same fashion, then we can do a structured clone underneath and avoid HTTP serialisation costs. That’s an optimisation that might not even produce benefits if the data is going cross-process. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cross origin communication and the navigator.connect API
On Wed, Dec 10, 2014 at 9:46 AM, Ehsan Akhgari ehsan.akhg...@gmail.com 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 prompting for the installation of the service worker, etc. 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 opportunity to install a SW. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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, jyass...@chromium.org 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://fetch.spec.whatwg.org/#http-fetch) specifies in step 13 that 'fetch' contexts go to the client's SW, not the target URL's SW. No, I don't think that's the proposal. As you point out that would have several problems. 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 makes a network request to https://a.com/apis/whatnot, it would first go to B's SW as per current SW specifications. But if that SW decides to forward the request to the network, then rather than directly hitting the network, first go to A's SW. Same thing if B's SW for any other reason makes a network request to https://a.com/apis/whatnot. Rather than directly hitting the network as is currently defined, we'd first go to A's SW. Yes, that is exactly what I had in mind. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 jo...@sicking.cc wrote: On Wed, Dec 10, 2014 at 1:02 PM, slightly...@google.com 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. We've avoided it thus far for these reasons. How does navigator.connect() address this problem? In Ehsan's proposal SW from site A would do a fetch() which starts the SW from site B. In the navigator.connect() proposal the SW from site A would do a navigator.connect() which starts the SW from site B. So the same number of SWs seem to be started, the only difference is the API that's used to start them, no? Hmm.. actually navigator.connect() does actually partially address this problem. It allows site A to talk to site B without using fetch() at all. Thus enabling A to avoid using the A SW at all. Though that particular goal could be reached by adding some of the optimizations that we talked about early on in SWs design. I.e. the ability for a SW to add rules like for this set of URLs, never wake me up and instead go directly to the network. Yeah, I suspect we may need to consider some optimizations along these lines for other reasons too. Again, there's still an important difference in syntax, which might accomplish some other goals that you are aiming for? I'm curious to know if the new syntax accomplishes anything else that I may have missed. Also, I'd like to reiterate that not using a new syntax will allow existing code to use SWs without any change, but a change in syntax means that all of the existing code using XHR (and soon fetch) needs to be rewritten to use navigator.connect, and perhaps fall back to actually talk to the network if the SW on the other side is not available to respond, which seems a lot more complicated. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 tc...@mozilla.com To: dev-b2g dev-...@lists.mozilla.org Sent: Tuesday, November 11, 2014 7:02:29 PM Subject: [b2g] Improve performance on multi-core device Hello, We opened bug 1093564 to improve the performance on quad-core (or more) devices, and currently we're working mainly on application launch time as it is the major requirement from partner. But indeed we want to improve the performance of user's daily use, so I am sending this email to collect things that you expect to be improved with more cores but it is not. That'd help us to have some ideas what to look into, and put them into the task queue. Thanks, Ting ___ dev-b2g mailing list dev-...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cross origin communication and the navigator.connect API
On Wed, Dec 10, 2014 at 6:22 PM, Alex Russell slightly...@google.com wrote: On Wed, Dec 10, 2014 at 5:48 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2014-12-10 7:45 PM, Jonas Sicking wrote: On Wed, Dec 10, 2014 at 4:22 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Dec 10, 2014 at 1:02 PM, slightly...@google.com 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. We've avoided it thus far for these reasons. How does navigator.connect() address this problem? In Ehsan's proposal SW from site A would do a fetch() which starts the SW from site B. In the navigator.connect() proposal the SW from site A would do a navigator.connect() which starts the SW from site B. So the same number of SWs seem to be started, the only difference is the API that's used to start them, no? Hmm.. actually navigator.connect() does actually partially address this problem. It allows site A to talk to site B without using fetch() at all. Thus enabling A to avoid using the A SW at all. Though that particular goal could be reached by adding some of the optimizations that we talked about early on in SWs design. I.e. the ability for a SW to add rules like for this set of URLs, never wake me up and instead go directly to the network. Yeah, I suspect we may need to consider some optimizations along these lines for other reasons too. I have a strong preference to consider that question independently of what we do for cross-origin service composition. I'm fine with considering that separately. But we can certainly look at optimizing away starting the initiating's site's SW separately. But adding new APIs to work around lack of optimizations in existing APIs doesn't seem like a good path forward. The notion that a SW author will need to be savvy to what's in another SW's caches (or, worse, the version of their SW) without the ability to have a preamble conversation (ala postMessage(), which is what n.c() proposes) is...disconcerting. I don't know how that becomes useful. I don't think anyone has proposed that there's cross website knowledge about what's cached and what's not? / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
