|
|
| (3 intermediate revisions by one other user not shown) |
| Line 1: |
Line 1: |
| == What the Client Does ==
| | #REDIRECT[[Services/Notifications/Push/Architecture]] |
| # Log in to Firefox with BrowserID. | |
| # Start Notifications client.
| |
| # Authenticate with Push Notification Service.
| |
| # Sync push URLs.
| |
| # Get stored messages.
| |
| # Get list of socket servers from Box Office.
| |
| # Connect to one of the socket servers, or backoff and retry.
| |
| # Get streamed messsages.
| |
| # Get new push URL (<tt>navigator.mozNotifcation.requestPermission()</tt>).
| |
| # Revoke push URL.
| |
| # Mark messages as read (synced with server).
| |
| # Maintain local DB of push URLs and site icons for displaying messages.
| |
| | |
| == Storage ==
| |
| Storage is keyed off a token generated from the BrowserID assertion. For each
| |
| user, we need to store a list of push URLs and a list of recent messages.
| |
| | |
| <b>Push URLs</b> need to be synced between user devices. They are persistent and
| |
| only deleted by user request.
| |
| | |
| <b>Recent messages</b> are stored on the server to support syncing messages between
| |
| devices. Messages will expire and be availble for garbage collection 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
| |
| will update their local state.
| |
| | |
| NB: when I talk about sync I don't necessarily mean Sync.
| |
| | |
| == Server Components ==
| |
| All the good ideas are based off talks with Urban Airship.
| |
| | |
| === Client API ===
| |
| HTTP endpoint supporting clients.
| |
| * Register client
| |
| * Create/revoke push URLs
| |
| * Sync push URLs
| |
| * Get list of unread messages when a client comes online
| |
| | |
| === Third-party site API ===
| |
| HTTP endpoint supporting third-party sites.
| |
| * Accept messages from third-party sites
| |
| * Pass messages to routing layer
| |
| | |
| === Box Office (BO) ===
| |
| When a client wants to connect to a socket server, the client asks BO for a
| |
| list of server IP addresses. BO returns multiple IP addresses for the client
| |
| to connect to. The client should try them in the returned order (BO can order
| |
| by decreasing free capacity). If the client can't connect, it should get a
| |
| 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.
| |
| | |
| === Socket Server ===
| |
| * Hold connections open to clients
| |
| * Send messages to client
| |
| * Send message-read to client
| |
| * Receive message-read from client
| |
| * Send push URL updates to client?
| |
| * Track connection state and share with Box Office
| |
| * <b>Not behind Zeus</b>
| |
| | |
| === Routing Layer ===
| |
| When a messages comes in through the API it needs to be routed to the correct
| |
| socket server(s) to get pushed to a client. There may be zero, one, or many
| |
| connected clients. Routing possibilities:
| |
| * Registry server that tracks which socket server(s) a client is connected to, and then:
| |
| ** direct RPC to the socket server
| |
| ** pub/sub to a channel for that server
| |
| * Open pub/sub: all socket servers listen to the same channel and pick out which messages they can send
| |