What WebRTC needs is related to the use cases I submitted for the Webapps charter update, for a Push API (based upon the concept presented at TPAC). Without presuming any implementation details at this point (even whether EventSource as it stands will fulfill this), we need the 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 call notifications (or other types of notifications).
This is a capability with broad utility, and we have been discussing the possibilities in W3C and beyond for several years. The first discussion in W3C was at the 2009 TPAC where I presented the concept for Connectionless Push to the HTML WG, with the result that the Server-Sent Events spec section on Connectionless Push was updated its current - although still informative - text. I have been leading work in other areas (e.g. the OMA and OMTP/WAC) on this API design, and in bringing the design ideas to Webapps in TPAC 2012 it was agreed in principle that work on such an API would be considered in the Webapps rechartering, given that it would be possible to bind to any underlying delivery system (whether standardized e.g. SMS, OMA Push, or other proprietary connectionless Push capabilities). On EventSource specifically, I believe its design can in principle be used to attach to event notification services independent of whether the actual over-the-air/wire protocol (bearer) at use at any one time is connection-oriented (e.g. HTTP as in typical SSE) or otherwise. This is the approach we have taken in OMA in defining the Push API which is nearing its final specification stage, and is based purely in SSE (and as a deployment option, transparently to the user agent). But while binding to specific bearers may be an implementation detail (there will be specific behaviors that will need to be implemented by the user-agent), there are some aspects that will need to be considered by the user agent which go beyond the current SSE spec, e.g. - persistent eventsource objects, i.e. creation of an eventsource (or something with the same general semantics) that exists whether the Webapp is running or not - ability of the user agent to invoke the Webapp when an event arrives, and the Webapp or the user agent itself is not running - binding of the incoming event data to the text/event-stream processing model used in eventsource - etc In considering these things, we may determine that SSE is not in fact the best match for this goal in W3C, but that's part of the proposed discussion in Webapps. Thanks, Bryan Sullivan -----Original Message----- From: Scott Wilson [mailto:[email protected]] Sent: Friday, March 09, 2012 6:35 AM To: Stefan Hakansson LK Cc: [email protected] Subject: Re: Regarding app notification and wake up On 9 Mar 2012, at 08:10, Stefan Hakansson LK wrote: > The webrtc WG has identified that the ability to notify, and possibly wake > up, a web application of incoming events is important. This to enable support > of use cases such as incoming calls. And in certain scenarios the resource > use (e.g. power) is very important. > > However, this kind of functionality is not in scope of the webrtc WG, but > seems to belong to the Web Applications WG. So this is a message that the > webrtc WG is interested in seeing technology that supports this being > developed. We have also noted discussions in Web Apps around use cases for > connection-less push: > <http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0008.html> - > especially the third one is very relevant for us. > > Stefan and Harald (chairs) for the webrtc WG. > Could server-sent events[1] meet this requirement? [1] http://dev.w3.org/html5/eventsource/
