3
edits
Talk:CloudServices/Notifications/Push/API: Difference between revisions
Jump to navigation
Jump to search
Talk:CloudServices/Notifications/Push/API (view source)
Revision as of 12:35, 5 February 2012
, 5 February 2012→Why not Permissions API?
(Why not Permissions API?) |
|||
| Line 4: | Line 4: | ||
Why then in this temporary spec have you opted to create a permissions API under remote Notifications, instead of specifying remoteNotification as a permission for this permissions API? | Why then in this temporary spec have you opted to create a permissions API under remote Notifications, instead of specifying remoteNotification as a permission for this permissions API? | ||
== A less privacy invading approach == | |||
On the server side we're looking at an HTTP interface that accepts POSTs with this attribute: | |||
* '''informationUrl:''' The URL from which the client will fetch a JSON document with the details of the notifications. This URL has to be in the same origin as the document that requested the notification permission. | |||
The document fetched by the browser from informationUrl looks like: | |||
* '''iconUrl:''' URL of the icon to be shown with this notification. | |||
* '''title:''' Primary text of the notification. | |||
* '''body:''' Secondary text of the notification. | |||
* '''actionUrl:''' URL to be opened if the user clicks on the notification. | |||
* '''replaceId:''' A string which identifies a group of like messages. If the user is offline, only the last message with the same replaceId will be sent when the user comes back online. | |||