Re: PSA: publishing new WD of Push API on April 30
Looks good to me. While we are continuing work on data payload encryption and alignment with the IETF Web Push Protocol, it makes sense to refresh the WD snapshot. Regards, Michael On Mon, Apr 27, 2015 at 2:39 PM, Arthur Barstow art.bars...@gmail.com wrote: This is an announcement of the intent to publish a new WD of Push API on April 30 using the following document as the basis: https://w3c.github.io/push-api/publish/TR.html (The sequence diagram is not found when the above document is loaded but the diagram will be available in the WD version.) If anyone has any major concerns with this proposal, please speak up immediately; otherwise the WD will be published as proposed. -Thanks, ArtB
Re: [Push] one or many
I filed an issue regarding the term webapp: https://github.com/w3c/push-api/issues/77 /m On Thu, Oct 9, 2014 at 7:52 PM, Michael van Ouwerkerk mvanouwerk...@google.com wrote: Indeed, the spec is currently inconsistent about registrations. The current intention is to have one per ServiceWorkerRegistration (i.e. per service worker). See for more details and discussion: https://github.com/w3c/push-api/issues/71 The term webapp does seem a bit odd to me. It's really just a web page. Is there a reusable concept I can link to for that? /m On Thu, Oct 9, 2014 at 7:08 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Oct 9, 2014 at 8:06 PM, Brian Kardell bkard...@gmail.com wrote: They do define it in the spec at least[1], but I don't see how it can mean both things. [1] http://www.w3.org/TR/push-api/#dfn-webapp That's not a definition that means anything. As I said, it's not grounded. -- https://annevankesteren.nl/
Re: [Webpush] IETF proposes new Web-Based Push Notifications Working Group
On Wed, Sep 24, 2014 at 3:20 PM, Arthur Barstow art.bars...@gmail.com wrote: [ Bcc webp...@ietf.org ] Hi All, I recall the IETF's intent to create a web-based push notifications protocol standard was previously announced on this list. Please note the draft charter for this WG explicitly mentions WebApps: [[ http://datatracker.ietf.org/doc/charter-ietf-webpush/ I think it will be very valuable to have a standardized push server protocol. ... This work will be done in collaboration with the W3C Webapps Working Group, who are developing a Web Push API for use in web applications (see http://www.w3.org/TR/push-api/). ]] The linked working draft is now more than a year old. The latest editor's draft has some inconsistencies while we transition to a service worker based system, but it's much closer to the current discussions: https://w3c.github.io/push-api/ I invite you all to contribute to the issues on the github project: https://github.com/w3c/push-api/issues I'm happy to continue making and reviewing pull requests. Again, additional contributors are very welcome! Regards, Michael If anyone has any comments or concerns about this, please speak up. -Thanks, AB Original Message Subject:[Webpush] WG Review: Web-Based Push Notifications (webpush) Date: Wed, 24 Sep 2014 06:19:19 -0700 From: The IESG iesg-secret...@ietf.org To: IETF-Announce ietf-annou...@ietf.org CC: webpush WG webp...@ietf.org A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2014-10-01. Web-Based Push Notifications (webpush) Current Status: Proposed WG Assigned Area Director: Alissa Cooper ali...@cooperw.in Mailing list Address: webp...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/webpush Archive: http://www.ietf.org/mail-archive/web/webpush/current/maillist.html Charter: Many applications require continuous access to network communications so that real-time events - such as incoming calls or messages - can be conveyed (pushed) to the user in a timely fashion. Uncoordinated use of the network by multiple applications can contribute to unnecessary use of the network on devices. For instance, maintaining sessions can dominate costs over the long term, since pushed events are relatively rare. This is particularly onerous for battery-powered devices, on which network communication contributes a significant proportion of power usage. Each independent session independently incurs overheads, causing unnecessary resource usage on devices. Several modern computing platforms provide a push notification service that consolidates application events, distributing those events to applications as they arrive. The single session avoids duplicated overhead costs on devices. This working group will develop a protocol that applications can use to request the delivery of data to a device using a consolidated push notification service. This protocol will include the ability to push the same message to multiple subscribed devices. The work may describe a protocol that allows a device to subscribe to a push service and receive pushed messages. This work will be done in collaboration with the W3C Webapps Working Group, who are developing a Web Push API for use in web applications (see http://www.w3.org/TR/push-api/). Milestones: Nov 2015 - Send web push protocol draft to the IESG as Proposed Standard ___ Webpush mailing list webp...@ietf.org https://www.ietf.org/mailman/listinfo/webpush
Re: [push-api] Identifying registrations
Hi Martin, note that the latest proposal is to have only a single
registration at a time:
http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0223.html
This means that unregister can remain on PushManager and requires no
arguments.
Yesterday I also posted a github issue with the suggestion to change the
unregister return value:
https://github.com/w3c/push-api/issues/4
Respec was fixed recently to support parameterization after this discussion:
http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0697.html
Regards,
Michael
On Tue, May 13, 2014 at 6:10 PM, Martin Thomson martin.thom...@gmail.comwrote:
On 13 May 2014 06:39, Michael van Ouwerkerk mvanouwerk...@google.com
wrote:
Martin, in Chrome we use registrationId and endpoint for distinct
purposes.
The endpoint is the push server url to which the app server posts new
messages. The registrationId identifies the correct {device, user, page}
to
which the message will be sent.
I think that the spec needs to be a lot clearer on the purpose (and
usage) of each of these things. Personally, I think that a better
model would be this:
interface PushManager {
PromisePushRegistration register();
PromisesequencePushRegistration registrations();
};
interface PushRegistration {
Promise unregister();
attribute DOMString id;
attribute DOMString endpoint;
};
interface PushMessage {
attribute PushRegistration registration;
attribute ?? data;
}
Yes, aside from moving unregister, it's just names, but sometimes
names are important. The reason behind moving unregister being that
'id' is only present for bookkeeping purposes, and many apps won't
have to use it.
That said, looking at this, I am sorely tempted to suggest adding
EventTarget to PushRegistration and use events. Any reason that
wouldn't be appropriate?
p.s., I assume that the mess in the editor's draft regarding
PushManager is due to a Respec.js issue around the use of promises.
Re: Push API register - vendor specific details
Jonas, your suggestions have a good point. I don't yet see a way around
having a sender id or push id though. I'll keep looking for a way to reduce
proprietary pieces in the API. But for the moment, the Push API as it is
seems hard to implement without proprietary extensions to it.
Thanks for your detailed reply.
/m
On Thu, Mar 20, 2014 at 7:35 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Mar 20, 2014 at 8:19 AM, Michael van Ouwerkerk
mvanouwerk...@google.com wrote:
An example call might look like this:
navigator.push.register({
gcmSenderId: 'some value',
apnsPushId: 'some other value'
});
Let me play devil's advocate a bit.
We have already given up on having the server side of push as a
standardized protocol for now. It seems like we are now doing the same
with the client side.
Given this, what is the advantage of having a push specification on
the form of what you are proposing, over having a push API that simply
looks like
x = navigator.pushProtocol; // gcm, apns, mozillapush
So the whole spec would be that single property. Possibly we would
also define the name for the ServiecWorker event that is used to
notify about incoming notifications.
After a page checks that property, it could then call a protocol
specific API and pass protocol specific arguments in order to do any
registration. Or if the protocol doesn't require a registration then
the page can simply do nothing. In order to push a message would send
a protocol specific network message to a protocol server.
You would then get the defined event in the ServiceWorker, but this
event contains protocol specific data. If the protocol supports
delivering a message body, then this body is included in the event.
In fact, if we encourage different protocol implementors to use
different names for the register push function, then we could use
normal feature detection (`if (registerGCMPush in navigator)`) and
get rid of the navigator.pushProtocol property too.
From a developer point of view, what would be the difference between
what you are proposing and this approach? Possibly you'd have to write
a slightly larger switch statement because the register for push
function might have different names in different protocols. But the
upshot is that we can make both registration and message delivery have
access to more protocol-specific features.
Neither approach really feels like a standard though.
And both solutions sets a bit of a scary precedence. The web succeeded
in part because it was based on standards. Standards that made the
same code run across all browsers that implemented that standard.
That said, I definitely appreciate the desire to integrate with
existing push servers. But I don't know how to do that while really
sticking with the goal of having a standardized web.
/ Jonas
Push API register - vendor specific details
To prevent abuse, many platforms require vendor specific registration
details for interacting with their push messaging systems. This allows e.g.
for banning spammers.
On Android, Google Cloud Messaging (GCM) is the canonical push messaging
system. Client registration requires passing a sender id and returns a
registration id:
http://developer.android.com/google/gcm/gs.html
iOS native apps:
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ProvisioningDevelopment.html
Safari Push Notifications (currently desktop only):
https://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/NotificationProgrammingGuideForWebsites/PushNotifications/PushNotifications.html#//apple_ref/doc/uid/TP40013225-CH3-SW1
This means that if the Push API is implemented around these systems, vendor
specific registration details must be provided.
How can we best manage the vendor specific details in the
navigator.push.register method?
The best suggestion I have heard is to give the register method a single
optional argument, which is a dictionary. Its attributes are optional and
it can be extended easily.
An example call might look like this:
navigator.push.register({
gcmSenderId: ‘some value’,
apnsPushId: ‘some other value’
});
I think this would be cleaner than e.g. user agent string parsing, and
serving different content based on that.
What do you think?
Regards,
Michael
Push API - use parameterized Promise types
In WebIDL we can now use parameterized Promise types:
http://heycam.github.io/webidl/#idl-promise
My suggestion is that we make some minor changes in the Push API spec to
take advantage of this. It reads much better and the prose can be
simplified.
The following promise types:
interface PushManager {
Promise register ();
Promise unregister (DOMString pushRegistrationId);
Promise registrations ();
};
Can be changed like this:
interface PushManager {
PromisePushRegistration register ();
PromiseDOMString unregister (DOMString pushRegistrationId);
PromisePushRegistration[] registrations ();
};
What do you think?
Regards,
Michael
Re: Push API - use parameterized Promise types
Ah I didn't know it has no effect on return values. Why not? /m On Thu, Mar 20, 2014 at 3:31 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Michael van Ouwerkerk mvanouwerk...@google.com It reads much better and the prose can be simplified. I am curious about the prose simplifications you mention? From talking to heycam, the value in the angle-brackets has no impact when used on the return type of a method, so I can't imagine it simplifying anything...
Re: Push API - use parameterized Promise types
So it is not normative? It seems it would be very informative though, so still worth adding to the spec. But it seems it would be even better if it was changed to be normative. Thanks, Michael On Thu, Mar 20, 2014 at 3:39 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Michael van Ouwerkerk mvanouwerk...@google.com Ah I didn't know it has no effect on return values. Why not? Well, I believe it's the same with all WebIDL method return values. If you return something that doesn't match the declared return value, that's a spec bug, but it has no impact on anything. (This is unlike argument values, where if the user passes in something that doesn't match the declared parameter type then conversion is performed.)
Re: Push API - use parameterized Promise types
Well, I interpreted your comment that way (it has no impact on anything). Maybe normative vs informative is not what you meant though? /m On Thu, Mar 20, 2014 at 3:56 PM, Domenic Denicola dome...@domenicdenicola.com wrote: I am not sure what you mean in this context by normative vs. informative. How would implementations differ if it were normative vs. if it were informative? -- From: Michael van Ouwerkerk mvanouwerk...@google.com Sent: 3/20/2014 11:46 To: Domenic Denicola dome...@domenicdenicola.com Cc: public-webapps public-webapps@w3.org Subject: Re: Push API - use parameterized Promise types So it is not normative? It seems it would be very informative though, so still worth adding to the spec. But it seems it would be even better if it was changed to be normative. Thanks, Michael On Thu, Mar 20, 2014 at 3:39 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Michael van Ouwerkerk mvanouwerk...@google.com Ah I didn't know it has no effect on return values. Why not? Well, I believe it's the same with all WebIDL method return values. If you return something that doesn't match the declared return value, that's a spec bug, but it has no impact on anything. (This is unlike argument values, where if the user passes in something that doesn't match the declared parameter type then conversion is performed.)
Re: [push-api] Dependency on System Messages
In Blink/Chrome we are looking into the Push API. We intend to use Service Workers as an alternative for System Messages. The idea is to fire an event in the SW when a push message is received. This has a big advantage: waking up a SW should be much faster than loading the whole document. Regards, Michael On Thu, Mar 13, 2014 at 11:45 AM, SULLIVAN, BRYAN L bs3...@att.com wrote: One of the other changes in progress is to include service workers on the design of the API. I don't know if that replaces system messages in total but the necessary changes will be considered when a new draft is submitted. Thanks, Bryan Sullivan On Mar 13, 2014, at 12:40 PM, Arthur Barstow art.bars...@nokia.com wrote: Hi Bryan, Eduardo, All, While working through the push notification versus push message thread, I noticed Push API directly refers to System Messages as defined by SysApps' [runtime] spec. Based on the Note at the top of [runtime], it appears work on that spec has stopped. As such, what is the plan for the Push API spec regarding the dependency on the System Messages feature? -Thanks, AB [runtime] http://runtime.sysapps.org/
Re: [push] Consider renaming push notification to push message in the Push API spec
I think that's a great suggestion Jeffrey. Specifically, I would like to avoid confusing concepts and terminology in the Push API with those in Web Notifications: http://www.w3.org/TR/notifications/ This is important because these two APIs are often discussed together: an app might display a notification to the user after receiving a push message from the server. Regards, Michael On Mon, Mar 10, 2014 at 6:14 PM, Jeffrey Yasskin jyass...@google.comwrote: The term push notification in https://dvcs.w3.org/hg/push/raw-file/tip/index.html#dfn-push-notification seems to confuse people into thinking that the user will be notified/bothered when such a message arrives. This is reinforced by the fact that iOS uses push notification for exactly that: a way to notify the user based on a message from a server. See https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/WhatAreRemoteNotif.html . Since the spec already uses the name PushMessage for the thing delivered by a push notification (https://dvcs.w3.org/hg/push/raw-file/tip/index.html#pushmessage-interface ), it seems like push message would be a good replacement for the current ambiguous name. Thanks, Jeffrey Yasskin P.S. I'm not subscribed to public-webapps@, so please cc me if you want me to reply.
