The Push Service issues the token to the User Agent.The User Agent then requests a token from the Push Service which authorizes delivery of notifications to that User Agent and App Client.The App Client asks the User Agent to authorize the delivery of notifications.How it does so is often proprietary and vendor/platform dependent.Įnabling notifications is a five step process: Push Service The push service ferries notifications from the App Server to the User Agent. User Agent The user agent is a service running locally on the user's device which receives push notifications and delivers them to the appropriate application. At minimum, the app server exists to trigger push notifications, but it often also performs business logic for the app. App Server The app server is a backend service for the app client.
#EJABBERD SAVE PENDING MESSAGES ON SERVER SOFTWARE#
This two-tiered push architecture allows the user's XMPP server to deliver notifications to arbitrary third-party clients, and in turn allows those clients to use the appropriate delivery mechanism for their platforms without having to share any private keys or other credentials with the XMPP server.Īpp Client The app client is the software installed and ran by the user, and is the final receiver of a push notification.
The third-party (and potentially proprietary or platform-dependent) push service delivers the notification from the client application's backend service to the user's device.The XMPP Push Service (as defined here) for a client application then delivers the notification to a third-party notification delivery service.The user's XMPP server publishes notifications to the XMPP Push Service of each of the user's client applications.XMPP Push works between the user's XMPP server and two push notification services in tandem: This document merely defines a "subset" or "profile" of XMPP publish-subscribe. The reader is referred to XEP-0060 for all relevant protocol details related to the XMPP publish-subscribe extension. Also, this document does not show error flows related to the generic publish-subscribe use cases referenced herein, since they are exhaustively defined in XEP-0060. Note: Any publish-subscribe use cases not described herein are described in Publish-Subscribe (XEP-0060). Eliminate the need for clients to proxy a user's XMPP session in order to enable push notifications.Allow clients to receive push notifications from multiple third-party XMPP servers.Allow XMPP servers to support push notifications to multiple client implementations, via multiple external or proprietary push services.The goal for this document is to make the generalized case possible, whereby a user may use their XMPP client of choice with their own server of choice. Proxied a user's session through the client provider's backend services in order to monitor for and trigger push notifications.Treated the XMPP client and XMPP server as one unified service, such that push notifications only worked using the "official" client.However, experience has shown that these implementations carried several drawbacks: There have been several push notification implementations by mobile XMPP client vendors.
Typically, these notifications are delivered to a user's mobile device, displaying a notice that can trigger opening an XMPP client to continue a conversation or answer a Jingle session request. The purpose of push notifications is to inform users of new messages or other pertinent information even when they have no XMPP clients online.
0 kommentar(er)
