259
edits
CloudServices/Notifications/Push/Arch: Difference between revisions
CloudServices/Notifications/Push/Arch (view source)
Revision as of 18:37, 6 April 2012
, 6 April 2012no edit summary
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
== What the Client Does == | == What the Client Does== | ||
# Log in to Firefox with BrowserID. | # Log in to Firefox with BrowserID. | ||
# Start Notifications client. | # Start Notifications client. | ||
| Line 7: | Line 7: | ||
# Get list of socket servers from Box Office. | # Get list of socket servers from Box Office. | ||
# Connect to one of the socket servers, or backoff and retry. | # Connect to one of the socket servers, or backoff and retry. | ||
# Get | # Get streaming messsages. | ||
# Get new push URL (<tt>navigator.mozNotifcation.requestPermission()</tt>). | # Get new push URL (<tt>navigator.mozNotifcation.requestPermission()</tt>). | ||
# Revoke push | # Revoke push URLs (user action). | ||
# Mark messages as read (synced with server). | # Mark messages as read (synced with server). | ||
# Maintain local DB of push URLs and site icons for displaying messages. | # Maintain local DB of push URLs and site icons for displaying messages. | ||
| Line 20: | Line 20: | ||
only deleted by user request. | only deleted by user request. | ||
<b>Recent messages</b> are stored on the server to support syncing messages between | <b>Recent messages</b> are stored on the server to support syncing messages | ||
devices. Messages will expire and be availble for garbage collection after | between devices. Messages will expire and be availble for garbage collection | ||
min(three days, sender-provided TTL). Clients can mark a message as read | after min(three days, sender-provided TTL). Clients can mark a message as read | ||
after user action (clicking on a message or clearing it), and other clients | after user action (clicking on a message or clearing it), and other clients will | ||
update their local state. | |||
NB: when I talk about sync I don't necessarily mean Sync. | NB: when I talk about sync I don't necessarily mean Sync. | ||
== Server Components == | == Server Components == | ||
All the good ideas are based off talks with Urban Airship. | All the good ideas are based off talks with Urban Airship. Each of the | ||
following sections can be built as a separate component so that no one piece | |||
can take down the whole system. They're partitioned based on the functionality | |||
they provide. | |||
=== Client API === | === Client API === | ||
HTTP endpoint supporting | HTTP endpoint supporting basic client operations. Clients would come here on | ||
startup to sync push URLs and stored messages. New push URLs are created when a | |||
site asks for push permission. | |||
* Register client | * Register client | ||
* Create/revoke push URLs | * Create/revoke push URLs | ||
| Line 39: | Line 45: | ||
=== Third-party site API === | === Third-party site API === | ||
HTTP endpoint supporting third-party sites. | HTTP endpoint supporting third-party sites. Notifications come into the system | ||
and are passed on to the routing layer. | |||
* Accept messages from third-party sites | * Accept messages from third-party sites | ||
* Pass messages to routing layer | * Pass messages to routing layer | ||
| Line 59: | Line 67: | ||
new list from the BO, using exponential backoff. If there are capacity | new list from the BO, using exponential backoff. If there are capacity | ||
problems BO can tell a client not to connect to any socket servers. | problems BO can tell a client not to connect to any socket servers. | ||
This could potentially be merged into the Client API component. | |||
=== Socket Server === | === Socket Server === | ||
The socket servers hold open persistent client connections and pass messages to | |||
sockets with minimal latency. They can't be behind Zeus due to licensing and | |||
scalability issues. | |||
* Hold connections open to clients | * Hold connections open to clients | ||
* Send messages to client | * Send messages to client | ||