Re: Service Workers meeting info

On 11/08/2016 11:41, Jake Archibald wrote: Notes were taken in IRC, here's a log https://gist.github.com/jakearchibald/c65009efa2ed9dbe3ad38f5fef5a4ef1. Here's my run-down of the headlines https://jakearchibald.com/2016/service-worker-meeting-notes/. Thanks Jake. Both added to the WP meetings

Re: Service Workers meeting info

Notes were taken in IRC, here's a log https://gist.github.com/jakearchibald/c65009efa2ed9dbe3ad38f5fef5a4ef1. Here's my run-down of the headlines https://jakearchibald.com/2016/service-worker-meeting-notes/. On Tue, 12 Jul 2016 at 11:52 Léonie Watson wrote: > Hello WP, > >

Service Workers meeting info

Hello WP, Information for the meeting on 28/29 July is here: https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-07-28-29SW.md If you plan to attend, it would be helpful if you could create a PR to add yourself to the attendees list (or let me know and I'll add you). Thanks.

Re: [Service Workers] meeting july/august?

On Thu, May 26, 2016 at 4:59 PM, Ben Kelly wrote: > On Wed, May 25, 2016 at 9:19 PM, Chaals McCathie Nevile < > cha...@yandex-team.ru> wrote: > >> Hi folks, >> >> at the last meeting people suggested another meeting in July/August. >> Should we be trying to schedule one? >> >

Re: [Service Workers] meeting july/august?

On Wed, May 25, 2016 at 9:19 PM, Chaals McCathie Nevile < cha...@yandex-team.ru> wrote: > Hi folks, > > at the last meeting people suggested another meeting in July/August. > Should we be trying to schedule one? > We'd actually already been discussing this between the last participants. Our

[Service Workers] meeting july/august?

Hi folks, at the last meeting people suggested another meeting in July/August. Should we be trying to schedule one? The Editing folks are meeting in California 29 July. Something just before that would be very convenient for *me*. Others of course may have unaccountably different

Re: [ServiceWorker] Expose GeoLocation to workers (#745)

I found a very interesting, and inspiring quote today that I'd like to share with you: - https://twitter.com/jaffathecake Googler. "I want the web to do everything native can, and fast." So can anyone here explain to me how that precludes device/user tracking? Or how HTML5 Web Apps can not be

Re: [ServiceWorker] Expose GeoLocation to workers (#745)

Look I %100 acknowledge the problem(s) @martinthomson highlights, and the need to prevent abuse from the black hats. All I’m saying is let’s work the problem rather than simply rocking in the foetal position, or worse, concocting artificial and exaggerated speed-humps on the release path of much

Re: [ServiceWorker] Expose GeoLocation to workers (#745)

@martinthomson I hate to make this a point of jurisdiction, but I think that this is a discussion that needs to be had in the geolocation working group. I've been careful to avoid any demarcation issues by always involving the Service Worker AND GeoLocation

Service Workers meeting, 11-12 April in Seattle

Hi all, there will be a meeting to work on Service Workers, scheduled for 11-12 April. Microsoft have kindly agreed to host it in Seattle (or thereabouts). An initial webpage for the meeting is in our github repo: https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/11-12aprSW.md

[workers]

กูนี้หละเจ้าพ่อ Heak ker

[service-workers] How can one use in-memory global state in Service Workers?

Experts on Service Workers: Per the spec ( https://slightlyoff.github.io/ServiceWorker/spec/service_worker/), global states will be discarded in between service worker restarts. This is understandable, however, it makes it impossible or too difficult to implement some use cases. Consider

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

1) Encryption between Alice and Bob by means of an asymmetric public/private key exchange protocol cannot be secure if both also exchange the keys and none has a method to verify the keys they got are the correct ones. Chuck who might control the gateway over which either Alice or Bob communicate

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

On Wed, Dec 2, 2015 at 9:36 AM, Florian Bösch wrote: > 1) Encryption between Alice and Bob by means of an asymmetric > public/private key exchange protocol cannot be secure if both also exchange > the keys and none has a method to verify the keys they got are the correct >

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

> > In DTLS, each handshake message is assigned a specific sequence >number within that handshake. When a peer receives a handshake >message, it can quickly determine whether that message is the next >message it expects. If it is, then it processes it. If not, it >queues it for

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

On Wed, Dec 2, 2015 at 10:01 AM, Florian Bösch wrote: > In DTLS, each handshake message is assigned a specific sequence >>number within that handshake. When a peer receives a handshake >>message, it can quickly determine whether that message is the next >>message

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

Le 01/12/2015 20:41, Brad Hill a écrit : >> As far as I see it, a "mixed content" has the word "content", which is > supposed to designate something that can be included in a web page and > therefore be dangerous. > > "Mixed Content" (and "mixed content blocking") is a term of art that has >

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte wrote: > > Then you should follow your rules and apply this policy to WebRTC, ie > allow WebRTC to work only with http. > Just as a sidenote, WebRTC also does UDP and there's no TLS over UDP. Also WebRTC does P2P, and there's

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

Le 02/12/2015 13:18, Florian Bösch a écrit : > On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte > wrote: > > Then you should follow your rules and apply this policy to WebRTC, ie > allow WebRTC to work only with http. > > > Just

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

> As far as I see it, a "mixed content" has the word "content", which is supposed to designate something that can be included in a web page and therefore be dangerous. "Mixed Content" (and "mixed content blocking") is a term of art that has been in use for many years in the browser community. As

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

Le 01/12/2015 05:31, Brad Hill a écrit : > Let's keep this discussion civil, please. Maybe some wording was a little tough below, apologies for this, the logjam attack is difficult to swallow, how something that is supposed to protect forward secrecy can do quietly the very contrary without

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

e that > such systems are unsecure or unlikely to happen, that's not true, see > the Flashproxy project too). > > But 1 fails too, because ws is not allowed inside a https page, so we > must use 2, which is insecure and 2 might not work any longer later. > >

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

. > > > > Even more, 1 is more secure than 4, because the Tor protocol is more > > secure than TLS. > > > > It's already a reality that projects are using something like 1 and > will > > continue to build systems on the same principles (one can'

WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

nue to build systems on the same principles (one can't argue that such systems are unsecure or unlikely to happen, that's not true, see the Flashproxy project too). But 1 fails too, because ws is not allowed inside a https page, so we must use 2, which is insecure and 2 might not work any longer lat

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

> > It's already a reality that projects are using something like 1 and will > continue to build systems on the same principles (one can't argue that > such systems are unsecure or unlikely to happen, that's not true, see > the Flashproxy project too). > > But 1 fails too, becau

RE: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

<vitteayme...@gmail.com>; Web Applications Working Group WG (public-webapps@w3.org) <public-webapps@w3.org> Cc: public-webapp...@w3.org Subject: Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine] I don't think there is universal agreement among browser engineer

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

ns to forbid ws with https, and ws with https with service > workers, and ws with https with future things, do you think that > browsers will continue to discuss in the future with good old entities > tied to a good old domain with a good old certificate? > > Then what about WebR

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

TPS. > > You may be interested in this Tor blog post that points out some > advantages of doing HTTPS over Tor: > > https://blog.torproject.org/blog/facebook-hidden-services-and-https-certs > > > > I am not a Tor advocate, this is just an example illustrating wh

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

On Mon, Nov 30, 2015 at 10:45 PM, Richard Barnes wrote: > 1. Authentication: You know that you're talking to who you think you're > talking to. > And then Dell installs a their own root authority on machines they ship, or your CA of choice gets pwn'ed or the NSA uses some

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

mple illustrating why there are no reasons to forbid ws with https, and ws with https with service workers, and ws with https with future things, do you think that browsers will continue to discuss in the future with good old entities tied to a good old domain with a good old certificate? Then what a

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

id ws with https, and ws with https with service workers, and ws with https with future things, do you think that browsers will continue to discuss in the future with good old entities tied to a good old domain with a good old certificate? Then what about WebRTC and DTLS self-sig

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

Let's keep this discussion civil, please. The reasons behind blocking of non-secure WebSocket connections from secure contexts are laid out in the following document: http://www.w3.org/TR/mixed-content/ A plaintext ws:// connection does not meet the requirements of authentication, encryption

Re: CfC: Is Web Workers Ready for CR? deadline Dec 14

On 11/30/15 8:31 AM, Xiaoqian Wu wrote: The latest [TEST RESULTS] of Web Workers indicate that Dedicated Workers have been widely implemented by the major browser vendors. Compatibly? Last I checked, for example, Blink doesn't support Dedicated Workers inside workers, only inside Window. I

Re: CfC: Is Web Workers Ready for CR? deadline Dec 14

> On 30 Nov 2015, at 10:02 PM, Boris Zbarsky <bzbar...@mit.edu> wrote: > > On 11/30/15 8:31 AM, Xiaoqian Wu wrote: >> The latest [TEST RESULTS] of Web Workers indicate that Dedicated Workers >> have been widely implemented by the major browser vendors. >

Re: CfC: Is Web Workers Ready for CR? deadline Dec 14

On 11/30/2015 02:31 PM, Xiaoqian Wu wrote: > This is a call for comments regarding the next step of Web Workers. > > The latest [TEST RESULTS] of Web Workers indicate that Dedicated > Workers have been widely implemented by the major browser vendors. > > [Diff] between

CfC: Is Web Workers Ready for CR? deadline Dec 14

This is a call for comments regarding the next step of Web Workers. The latest [TEST RESULTS] of Web Workers indicate that Dedicated Workers have been widely implemented by the major browser vendors. [Diff] between the latest W3C WD and the WHATWG living standard suggests substantial changes

RE: RfC: Service Workers and "Portable Web Publications for the Open Web Platform"

Hi Jake, Thanks for the offer. The DPUB IG meets on Mondays at 11:00 EDT/15:00 UTC. We would be very happy to have you at our 19 October meeting [1] to discuss Service Workers in the context of the Portable Web Publications for the Open Web Platform [2]. Markus and I will copy you when we

Re: RfC: Service Workers and "Portable Web Publications for the Open Web Platform"

Jake, just to note that Tzviya, who organizes the meetings around TPAC, is on vacations until Wednesday morning. We will synchronize then; I hope it is all right. And thanks in advance for your help! Ivan --- Ivan Herman Tel:+31 641044153 http://www.ivan-herman.net (Written on mobile, sorry

RfC: Service Workers and "Portable Web Publications for the Open Web Platform"

Hi All, The Digital Publishing Interest Group [1] is seeking feedback regarding the use of Service Workers in their early draft (WIP) of "Portable Web Publications for the Open Web Platform", in particular section 5.1 "General Architecture for Online/Offline Publicati

Re: RfC: Service Workers and "Portable Web Publications for the Open Web Platform"

On Mon, 5 Oct 2015 at 13:00 Arthur Barstow wrote: > The IG welcomes discussion and feedback during their October 19 > conference call (if interested, please contact Tzviya) and/or during > TPAC. I'm happy to take part in this from a service worker point of view, if

RE: RfC: Service Workers

a feature. It is an architecture. > -Original Message- > From: Arthur Barstow [mailto:art.bars...@gmail.com] > Sent: Monday, September 21, 2015 5:27 AM > To: public-webapps > Subject: Re: RfC: Service Workers > > Please use the Version 1 branch for this review: > <https://sli

Re: RfC: Service Workers

On 9/23/15 1:46 PM, Phillips, Addison wrote: Could you better define what "soon" means? More specifically, do you have a deadline for comments? I don't see any dates in the thread below. I think four weeks is the `normal` expectation for `wide reviews`. However, the Editors and some active

Re: RfC: Service Workers

e list (public-review-announce), Geolocation WG (public-geolocation) ] The Editors and active contributors of Service Workers intend to publish a Candidate Recommendation soon (details below). Consequently, this is a Request for Comments by the WebApps group to seek wide review of the latest v

Re: Normative references to Workers.

On 9/21/15 5:54 AM, Ms2ger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/21/2015 11:05 AM, Xiaoqian Wu wrote: If it helps, I’d like to prepare a Workers draft to revise the previous CR, and schedule the publication ASAP (hopefully 22 Sep). The goal is to synchronise

Re: Normative references to Workers.

On Mon, Sep 21, 2015 at 6:03 PM, Arthur Barstow <art.bars...@gmail.com> wrote: > On 9/21/15 5:54 AM, Ms2ger wrote: >> Why? > > I think the rationale was mentioned in > <https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0367.html>. Ms2ger made a valid po

RfC: Service Workers

[ Bcc: TAG (www-tag), WebAppSec WG (public-webapsec), Mobile IG (public-web-mobile), W3C Chairs (chairs), Review Announce list (public-review-announce), Geolocation WG (public-geolocation) ] The Editors and active contributors of Service Workers intend to publish a Candidate Recommendation

Re: Normative references to Workers.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/21/2015 11:05 AM, Xiaoqian Wu wrote: > If it helps, I’d like to prepare a Workers draft to revise the > previous CR, and schedule the publication ASAP (hopefully 22 Sep). > The goal is to synchronise with the upstream, to

Re: Normative references to Workers.

oned in >> <https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0367.html>. > > Ms2ger made a valid point. Workers is actively being updated (I > submitted two PRs the other day, more to come). If you don't want to > get out-of-sync you won't get to REC in the

RE: Normative references to Workers.

From: Xiaoqian Wu [mailto:xiaoq...@w3.org] > If the spec is still changing frequently, indeed it isn't a good idea to > publish another CR… but the WebApps WG needs to clearly tell the community > that the 2012 CR should be considered obsolete. > > I’d suggest that we publish a

Re: Normative references to Workers.

erence Policy [NRP] supports such a scenario. > > In this specific case, I don't believe anyone has committed to actively > maintain W3C Web Workers. As such, WebApps - do we have a volunteer? Please > let us know (or send me private e-mail if you prefer). If it helps, I’d lik

Service Workers 1 and Nightly

Hi all, We editors are happy to announce that we make a new branch for Service Workers 1 today [1]. Thanks to all the contributions, Service Workers 1 now covers the fundamental model and the associated APIs to support offline-first and background processing requirements. The features

Re: Service Workers 1 and Nightly

On 9/18/15 2:22 AM, Jungkee Song wrote: Hi all, We editors are happy to announce that we make a new branch for Service Workers 1 today [1]. Thanks to all the contributions, Service Workers 1 now covers the fundamental model and the associated APIs to support offline-first and background

Re: Service Workers 1 and Nightly

On Fri, Sep 18, 2015 at 7:56 PM, Arthur Barstow wrote: > > Regarding the publishing plan above, the latest process document includes > an expectation that before a CR is published the spec "has already received > wide review" [1]. Although the group is free to determine

Re: Normative references to Workers.

tively referencing a WHATWG spec would (IMHO) be appropriate and I think the Normative Reference Policy [NRP] supports such a scenario. In this specific case, I don't believe anyone has committed to actively maintain W3C Web Workers. As such, WebApps - do we have a volunteer? Please let us know (o

Re: Normative references to Workers.

On Tue, Sep 15, 2015 at 10:31 AM, Mike West <mk...@google.com> wrote: > The "Upgrade Insecure Requests" specification[1] references the WHATWG HTML > spec for the > "set up a worker environment settings object" algorithm[2], as the Web > Workers Ca

Normative references to Workers.

The "Upgrade Insecure Requests" specification[1] references the WHATWG HTML spec for the "set up a worker environment settings object" algorithm[2], as the Web Workers Candidate Recommendation from May 2012[3] substantially predates the entire concept of a "settings object

Re: Normative references to Workers.

On Tue, 15 Sep 2015, Mike West wrote: > > It seems appropriate, then, to bring the question to this group: does > WebApps intend to update the Workers draft in TR? FWIW, I think the W3C should get out of the business of republishing WHATWG specifications. It's just adding confusion, e

Re: Normative references to Workers.

On Tue, Sep 15, 2015 at 11:25 AM, Tab Atkins Jr. wrote: > ​there's nothing wrong with reffing WHATWG specs. It will not delay > ​ or hamper​ > > publication or Rec-track advancement, despite the > ​ occasional misinformed​ > > complaint from someone not aware of the > ​ ​

Re: Normative references to Workers.

that the Web Application Security group never asked for a review from the Web Applications working group prior to asking for transition to CR. As a consequence, the WebApps group did not get an opportunity to review the Upgrade Insecure Resources specification [1], including the reference related to

RE: PSA: publishing new WD of Service Workers on June 25

://html.spec.whatwg.org/multipage/infrastructure.html#in-parallel. Will add the links. Jungkee -Original Message- From: timeless [mailto:timel...@gmail.com] Sent: Wednesday, July 01, 2015 1:23 PM To: public-webapps Subject: Re: PSA: publishing new WD of Service Workers on June 25 http

Re: PSA: publishing new WD of Service Workers on June 25

http://slightlyoff.github.io/ServiceWorker/publish/service_worker/WD-service-workers-20150625/ Invoke Run Service Worker algorithm with serviceWorker as the arguement [sic]. Fetch invokes Handle Fetch with request. As a result of performing Handle Fetch, the Service Woker [sic] returns

PSA: publishing new WD of Service Workers on June 25

This is an announcement of the intent to publish a new Working Draft of Service Workers on June 25 using the following document as the basis: http://slightlyoff.github.io/ServiceWorker/publish/service_worker/WD-service-workers-20150625/ If anyone has any major concerns with this proposal

PSA: publishing new WD of Service Workers on February 5

The Service Workers editors - which now includes Jake Archibald (thanks Jake!) - would like to publish a new WD of Service Workers and the proposed publication date is February 5: https://slightlyoff.github.io/ServiceWorker/publish/service_worker/WD-service-workers-20150205/ If anyone has any

Re: Clarification of CSP sandbox and workers

On Thu, Nov 6, 2014 at 5:10 AM, Deian Stefan de...@cs.stanford.edu wrote: I am implementing CSP for Workers in Firefox, but like to get a clarification on workers and the sandbox flag. Currently, a Worker can inherit or be accompanied by a CSP header. As written, the implications

Re: Clarification of CSP sandbox and workers

The CSP spec should just delegate to HTML here. If/when HTML defines sandboxing with regard to Workers, CSP will just start using those hooks. I'd agree, for example, that it does appear that sandboxing a worker into a unique origin could be interesting. It's not clear to me whether any

Re: Clarification of CSP sandbox and workers

+1 Mike West mk...@google.com writes: The CSP spec should just delegate to HTML here. If/when HTML defines sandboxing with regard to Workers, CSP will just start using those hooks. Reasonable, the issue also appears outside CSP: if I create a worker in a sandboxed iframe, what should its

Re: Clarification of CSP sandbox and workers

On Wed, 12 Nov 2014, Mike West wrote: The CSP spec should just delegate to HTML here. If/when HTML defines sandboxing with regard to Workers, CSP will just start using those hooks. I'd agree, for example, that it does appear that sandboxing a worker into a unique origin could

PSA: publishing new WD of Service Workers on November 13

Jungkee and Alex created a new Working Draft of Service Workers for publication as a Technical Report on November 13: http://slightlyoff.github.io/ServiceWorker/publish/service_worker/WD-service-workers-20141113/ If anyone has any major concerns this proposal, please speak up as soon

Clarification of CSP sandbox and workers

Hey guys, I am implementing CSP for Workers in Firefox, but like to get a clarification on workers and the sandbox flag. Currently, a Worker can inherit or be accompanied by a CSP header. As written, the implications of the sandbox directive on the Worker context is not clear. [Following up

WebApps-ACTION-745: Followup with simon re running the web workers tests

WebApps-ACTION-745: Followup with simon re running the web workers tests http://www.w3.org/2008/webapps/track/actions/745 Assigned to: Arthur Barstow

Re: Push API and Service Workers

On 10/22/14 1:21 AM, Shijun Sun wrote: On Tuesday, October 21, 2014 2:27 PM, Arthur Barstow wrote: If we want to take advantage of this opportunity, perhaps you should first flesh out specific issue(s) to discuss, and then try to agree on a time + day slot in advance of the meeting. Thanks

RE: Push API and Service Workers

. Shijun - I just added a 13:00-13:30 Push API slot on Monday October 27: Thanks Arthur! Since we could touch the Service Workers topics (e.g. [1][2]), I expect it'd be more productive for folks having hands-on experience with Service Workers to participate. Best, Shijun [1] https://github.com

Re: Push API and Service Workers

and options in the whole E2E story. Shijun - I just added a 13:00-13:30 Push API slot on Monday October 27: Thanks Arthur! Since we could touch the Service Workers topics (e.g. [1][2]), I expect it'd be more productive for folks having hands-on experience with Service Workers to participate. Good

Re: Push API and Service Workers

On Tue, Oct 21, 2014 at 7:25 AM, Erik Corry erikco...@google.com wrote: * Push doesn't actually need SW's ability to intercept network communications on behalf of a web page. * You can imagine a push-handling SW that does all sorts of complicated processing of notifications, downloading things

Re: Push API and Service Workers

On Thu, Oct 23, 2014 at 2:27 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Oct 21, 2014 at 7:25 AM, Erik Corry erikco...@google.com wrote: * Push doesn't actually need SW's ability to intercept network communications on behalf of a web page. * You can imagine a push-handling SW that

RE: Push API and Service Workers

On 21 Oct 2014 16:53, Shijun Sun shij...@microsoft.com wrote: On Monday, October 20, 2014 9:42 AM, Jake Archibald wrote: Things I guess you'd do as a result of a push message: One of the most typical scenarios is * show a toast notification (e.g. for a new email) * user chooses to dismiss

Re: Push API and Service Workers

On 10/16/14 5:52 PM, Shijun Sun wrote: On Thursday, October 16, 2014 11:46 AM, Martin Thomson wrote If the push message is being used to deliver a call notification, that sort of delay will definitely be noticed. And I'm assuming that you've tested on a high end Nexus or something like that.

RE: Push API and Service Workers

On Tuesday, October 21, 2014 2:27 PM, Arthur Barstow wrote: If we want to take advantage of this opportunity, perhaps you should first flesh out specific issue(s) to discuss, and then try to agree on a time + day slot in advance of the meeting. Thanks Arthur for the suggestion. I think

Re: Push API and Service Workers

On 19 October 2014 19:18, Shijun Sun shij...@microsoft.com wrote: It'd be great if the Push API spec allows the web developers to have flexibility to leverage the generic actions, or rely on a service worker, or maybe doing both. I imagine that we will permit the use of whatever a service

RE: Push API and Service Workers

On Monday, October 20, 2014 5:41 AM, Martin Thomson wrote: I imagine that we will permit the use of whatever a service worker has access to. Some of that is going to require prior arrangement (i.e., consent prompts might be required to enable a full screen alert, though maybe toasts). Fully

Re: Push API and Service Workers

On 20 October 2014 03:18, Shijun Sun shij...@microsoft.com wrote: What I'd like to get across is when the push client can handle generic actions already, such as posting a toast notifications, waking up the browser (or a subset of it) and let service workers to display each notification might

Re: Push API and Service Workers

On Wed, Oct 15, 2014 at 3:07 PM, Shijun Sun shij...@microsoft.com wrote: My understanding here is that we want to leverage the push client in the OS. That will provide new capabilities without dependency on a direct connection between the app and the app server. Yes, this is how the spec is

RE: Push API and Service Workers

the browser (or a subset of it) and let service workers to display each notification might not be the best practice from performance perspective, especially when the user does not want to pick up each incoming video call or read each incoming emails right away. It'd be great if the Push API

Re: Push API and Service Workers

On Wed, Oct 15, 2014 at 3:07 PM, Shijun Sun shij...@microsoft.com wrote: My understanding here is that we want to leverage the push client in the OS. That will provide new capabilities without dependency on a direct connection between the app and the app server. You are correct about

Re: Push API and Service Workers

On Thu, Oct 16, 2014 at 5:22 PM, Shijun Sun shij...@microsoft.com wrote: This is very helpful. I assume the browser running the service worker can be a very light-weight version (or a subset of the full browser) since we don't need to render an actual webpage. Is that the right expectation?

RE: Push API and Service Workers

On Thursday, October 16, 2014 8:29 AM, Anne van Kesteren wrote On Thu, Oct 16, 2014 at 5:22 PM, Shijun Sun shij...@microsoft.com wrote: (1) the Push Client displays a notification right away, the user chooses to pick up the call or dismiss, the browser launch with the app based on user

Re: Push API and Service Workers

On 16 October 2014 08:55, Shijun Sun shij...@microsoft.com wrote: Re #2, it'd be great if some folks could comment on the scheduling and latency question. There are number of variations on how this all works out. And multiple sources of latency. A mobile device in a low power state follows a

Re: Push API and Service Workers

of the full browser) since we don't need to render an actual webpage. Is that the right expectation? Yes, the subset required by Service Workers consists of things like a JavaScript engine, network stack, local storage, and an implementation of the APIs exposed to Service Workers. But you don't need

Re: Push API and Service Workers

On 16 October 2014 11:17, John Mellor joh...@google.com wrote: In our prototype on Android, it takes less than a second (not yet optimized) to wake up Chrome from a cold start and handle the event in a Service Worker (the demo writes to IndexedDB and shows a notification), versus less than

RE: Push API and Service Workers

On Thursday, October 16, 2014 11:46 AM, Martin Thomson wrote If the push message is being used to deliver a call notification, that sort of delay will definitely be noticed. And I'm assuming that you've tested on a high end Nexus or something like that. Add the latencies involved in

Push API and Service Workers

Hi, I'm with the IE Platform team at Microsoft. I joined the WebApps WG very recently. I am looking into the Push API spec, and got some questions. Hope to get help from experts in the WG. The current API definition is based on an extension of the Service Workers. I'd like to understand

RE: Push API and Service Workers

I'm not an expert either, but it seems to me that push without service workers (or some other means of background processing) is basically just server-sent events. That is, you could send push notifications to an active webpage over a server-sent events channel (or web socket, or long-polling

RE: Push API and Service Workers

, October 15, 2014 2:59 PM To: Shijun Sun; public-webapps Subject: RE: Push API and Service Workers I'm not an expert either, but it seems to me that push without service workers (or some other means of background processing) is basically just server-sent events. That is, you could send push

Re: Push API and Service Workers

The hard question is: What do you do if there's an incoming push message for a given website, but the user doesn't have the website currently open. Service Workers provide the primitive needed to enable launching a website in the background to handle the incoming push message. Another solution

Re: Push API and Service Workers

On 15 October 2014 23:07, Shijun Sun shij...@microsoft.com wrote: My understanding here is that we want to leverage the push client in the OS. That will provide new capabilities without dependency on a direct connection between the app and the app server. The Push API doesn't use a direct

Re: Push API and Service Workers

On 15 October 2014 14:58, Domenic Denicola dome...@domenicdenicola.com wrote: So from my perspective, implementing the push API without service workers would be pretty pointless, as it would give no new capabilities. That's not strictly true. If I sit (as I do) with a tab open to gmail

RE: Push API and Service Workers

the trigger from what to do when the trigger fires. Which both makes for a smaller API, and for a more flexible design. That is a valid argument. To be clear, my question right now is not whether we need Service Workers in the spec. I'd like to understand how that works in typical scenarios and whether

[Bug 24691] Allow shared Web workers to persist across page loads from same origin

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24691 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 26957] Allow sending DOM objects to Workers and expose a DOM (or DOM-like) interface to workers

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26957 Ms2ger ms2...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Bug 26957] New: Allow sending DOM objects to Workers and expose a DOM (or DOM-like) interface to workers

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26957 Bug ID: 26957 Summary: Allow sending DOM objects to Workers and expose a DOM (or DOM-like) interface to workers Product: WebAppsWG Version: unspecified Hardware: PC

  1   2   3   4   5   6   7   >