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
On October 24, 2014 4:30 AM, Arthur Barstow wrote:
On 10/22/14 1:21 AM, Shijun Sun wrote:
I think we can take a half hour timeslot to discuss the E2E flow for the RTC
scenarios using push messages. The goal is to make sure we understand the
steps and options in the whole E2E story.
point. Since Jungkee is attending the meeting (and I'll chase after
Alex to see if he can join), I created a 13:00-14:00 Push API and
Service Workers block on Monday and added links to the 2 issues below.
https://www.w3.org/wiki/Webapps/November2014Meeting#Agenda_Monday_October_27
-Art
Best
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
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
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
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.
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
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
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
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
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
On Sunday, October 19, 2014 6:43 PM, Jonas Sicking wrote:
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
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
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?
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
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
On 16 October 2014 16:22, Shijun Sun shij...@microsoft.com wrote:
On Thursday, October 16, 2014 12:42 AM, Anne van Kesteren wrote:
You need a browser to run a service worker. The browser is pinged and it
might then decide to start running a service worker to process the incoming
message, or
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
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
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
...), which would
allow it to display a toast notification with the push message.
So from my perspective, implementing the push API without service workers would
be pretty pointless, as it would give no new capabilities.
, 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
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
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
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
Thanks folks for the quick responses to the questions!
RE: [Martin Thomson] If I sit (as I do) with a tab open to gmail for a very
long time, then it is of some advantage to me (and my network usage) to use
something like push rather than websockets (or even server sent events).
Besides,
27 matches
Mail list logo
