WebAPI/Push/Requirements: Difference between revisions
Jump to navigation
Jump to search
(Created page with " == Push Project Requirements == * No open TCP sockets ** In order to reduce network load, clients should not be required to hold a TCP socket open in order to receive notificat...") |
No edit summary |
||
| (8 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
== Push Project Requirements == | == Push Project Requirements == | ||
<strike> | |||
* No open TCP sockets | * No open TCP sockets | ||
** In order to reduce network load, clients should not be required to hold a TCP socket open in order to receive notifications. | ** In order to reduce network load, clients should not be required to hold a TCP socket open in order to receive notifications. | ||
** Network operators should be able to use UDP broadcast to 'wake up' client who then | ** Network operators should be able to use UDP broadcast (or other standarized mechanism, like WapPUSH, SMS) to 'wake up' client who then should establish a TCP connection to Push Server.</strike> | ||
* No continuously open TCP sockets on mobile devices (previous requirement obsoleted by WebRTC new server initiated connection requirement) | |||
** Connection between provider proxy to the Push server and the device will be determined by the provider. | |||
** Provider must allow proxy to hold open a proxied socket to the Push Server, and must relay served notification alerts to devices in a timely manner. | |||
* Multiple connections (signal | * Multiple connections (signal versus signal+data) | ||
** Push system should not require a second TCP connection for data/notification fetching | ** Push system should not require a second TCP connection for data/notification fetching | ||
*** Mozilla believe that this may be a premature optimization. | *** Mozilla believe that this may be a premature optimization. | ||
| Line 21: | Line 23: | ||
* Data privacy | * Data privacy | ||
** Push server should not be able to inspect application private data | ** Push server should not be able to inspect application private data | ||
** No disclosure of personal identifiable info to application (e.g. MSISDN) | |||
* Push system scalability | * Push system scalability | ||
** Push system must be able to be scaled to tens of millions. | ** Push system must be able to be scaled to tens of millions. | ||
*** Order of mag smaller than apple or android's system. | *** Order of mag smaller than apple or android's system. | ||
** System must be allowed to support multiple push servers | ** System must be allowed to support multiple (and possibly federated) push servers | ||
Nice-to-have features: | |||
* Multicast notifications (e.g. all instance of the same user), broadcast (e.g. all instances of the app) through a single request from app server to the push server | |||
* Special type of notifications with real-time requirements (e.g. notification of an incoming VoIP call) which are delivered with minimized delay. | |||
Non Goals: | |||
* | |||
[[Category:Web APIs]] | |||
Latest revision as of 23:56, 1 October 2014
Push Project Requirements
No open TCP sockets- In order to reduce network load, clients should not be required to hold a TCP socket open in order to receive notifications.
Network operators should be able to use UDP broadcast (or other standarized mechanism, like WapPUSH, SMS) to 'wake up' client who then should establish a TCP connection to Push Server.
- No continuously open TCP sockets on mobile devices (previous requirement obsoleted by WebRTC new server initiated connection requirement)
- Connection between provider proxy to the Push server and the device will be determined by the provider.
- Provider must allow proxy to hold open a proxied socket to the Push Server, and must relay served notification alerts to devices in a timely manner.
- Multiple connections (signal versus signal+data)
- Push system should not require a second TCP connection for data/notification fetching
- Mozilla believe that this may be a premature optimization.
- Push system should not require a second TCP connection for data/notification fetching
- Easy-to-use API
- A design goal for *all* web apis.
- Default should be safe, and ensures end to end privacy of data
- Must not require applications to do their own crypto
- Guaranteed delivery
- Push system should guaranteed a timely delivery of notification
- Push system should be able to recover from data center loss
- Data privacy
- Push server should not be able to inspect application private data
- No disclosure of personal identifiable info to application (e.g. MSISDN)
- Push system scalability
- Push system must be able to be scaled to tens of millions.
- Order of mag smaller than apple or android's system.
- System must be allowed to support multiple (and possibly federated) push servers
- Push system must be able to be scaled to tens of millions.
Nice-to-have features:
- Multicast notifications (e.g. all instance of the same user), broadcast (e.g. all instances of the app) through a single request from app server to the push server
- Special type of notifications with real-time requirements (e.g. notification of an incoming VoIP call) which are delivered with minimized delay.
Non Goals: