Use cases for EventSource extension to other Push bearers
Addressing the Webapps charter item related to Server-Sent Events extension (as one potential approach), i.e. "The API may be extended to work with or include other push notification schemes such as Push SMS or the ability to wake a 'sleeping' application, as discussed on the working group mailing list."
- One of Bob’s most-used apps is a social networking webapp which enables him to remain near-realtime connected to his friends and colleagues. During his busy social hours, when he’s out clubbing, his phone stays pretty much connected full time, with a constant stream of friend updates. He likes to remain just as connected though during less-busy times, for example during the workday as friends post their lunch plans or other updates randomly. While he wants his favorite app to remain ready to alert him, he doesn’t want the app to drain his battery just to remain connected during low-update periods.
- Alice is a collector, and is continually watching or bidding in various online auctions. When auctions are about to close, she knows the activity can be fast and furious and is usually watching her auction webapp closely. But in the long slow hours between auction closings, she still likes for her webapp to alert her about bids and other auction updates as they happen, without delay. She needs for her auction webapp to enable her to continually watch multiple auctions without fear that its data usage during the slow periods will adversely impact her profits.
- Bob uses a web based real-time communications service and he wants to be available to his friends and family even when his application is not running. Bob travels frequently and it is critical for him to optimize data usage and preserve battery. Bob’s friends can call him up to chat using video/audio or just text and he wants to make sure they can reach him irrespective of what device and what network he is connected at any given time.
- ability of Webapps to register for events to be delivered whether the Webapp (or even the user agent) is running or not. This will ensure that the Webapp does not have to maintain an always-on connection in order to receive incoming notifications.
- ability to define bindings to various underlying delivery systems (whether standardized e.g. SMS, OMA Push, SIP (e.g. MESSAGE or INVITE/MSRP), or other proprietary connectionless or connection-oriented Push capabilities)
- if defined to use EventSource, binding of the incoming event data to the text/event-stream processing model used in EventSource connections, or some new processing model compatible with the EventSource design, if more flexibility is needed
- if defined using some other API, definition of an event processing model that enables content and metadata (e.g. headers) to be delivered unhindered to the Webapp
- the API should enable Webapp client and server to coordinate whatever connectionless/shared delivery system is to be used along with the appropriate addressing scheme and address, prior to a bearer switch (or in the setup of the original connection)
- ability to direct events to a specific Webapp even if there is no Webapp-specific connection over which the events are delivered to the device
- ability to direct events intended for a specific Webapp, to it alone
- ability to apply filters on which events are delivered to the Webapp, e.g. based presence of specific strings in the event data (e.g. a header value identifying a target application or content type), or specific event source addresses, so a Webapp does not need to worry about handling events it did not ask for.
- ability to deliver an event to a Webapp, and allow the Webapp to do some initial processing of the event prior to Webapp content or browser UI/chrome being shown
- ability to buffer event data until the application is ready to receive the event
- ability to base security upon same-origin policy and CORS
- ability to apply other security models (e.g. managed permissions) if necessary for a particular binding