From MozillaWiki
Jump to: navigation, search

From https://etherpad.mozilla.org/SimplePush

Questions to be answered: Immediate short term,

   Client only that talks to a server.
       Close to being reviewable
           QA on board?

Q2 for the delivery of the Moz server

   Connections stand: 1MM by end of the year.
       Need to support desktop and android?
       plus additional mobile?
   Don't know what desktop UX looks like. 
       No change to base API, but interaction points may change.
   not sure if TEF is expecting large load. 
   Multiple push servers. 
       Do clients connect to multiple push servers?
           * Single Push server per user agent.
   Current implemtation is rest like
   Using websocket for heartbeat (problem with gecko)
       mmayo expressed some concern about routers interacting with websocket.
   Still some room for adjusting the API. 
       Need to pick between REST and WS (favor websocket)
       Android Java will need WS client library.
   TEF server is node.js w/ mongo data backend and rabbit for queuing.
       Weather app:
           reduce the request from AppServer
           reduce the impact to AppServer on wake
           App Server determines grouping via CRUD
           Add data token for notification.
               PII, TTL, Delivery assurance, 
               * feedback to App Server about client unsub
       Do we ever sleep?
           How do we differentiate between WebRTC and MLP fan messages?
           WS ping/pong only for networks that don't do UDP wakes.
               Server needs to know if client is wakeable
           Moz server only focus on non UDP wake messages.
           Server can presume WS connection is live. 
           Land in moz 22.
           18 ops devel b2g phones
               5 to do push
               when can we have a server running?
                   Supporting <1MM connections?
                   base What'sApp?

Current Requirements:

   Use Cases 
       * Delayed Event Notice
       * Limited user presence (for WebRTC connect)
       * when a tab is closed, still need to communicate to browser and notify thing happens.
       * WebRTC defines length of connection.
           * Sub 30 second connect
           * Browsers will dwarf mobile.
   System Reqs:
       * WebSocket based
       * Need recovery
       * Support extension for Vendor Provided wakeup.
       * Support 10MM simultaneous connections
       * Robust messages?

Desired Elements:

   * Full user presence (for WebRTC connect)
   * limited, lossy messaging to client
   * broadcast


   * review websocket API
   * How many sockets supported per box?