Re: Regarding app notification and wake up
I second Bryan's request. Having apps that need to monitor remote events each spawn a (shared)worker to do so could drain a phone's battery very quickly. There needs to be a system-level way to do this. --tobie On 3/12/12 11:47 PM, SULLIVAN, BRYAN L bs3...@att.com wrote: Karl, excellent questions. Re (1), there are various systems of device addressing in use today, largely dependent upon the notification delivery system. An assumption to start with is that barring any optimizations which enable seamless switching between SSE connections and connectionless delivery (which requires a delivery agent/client on the device, feasible but still an optimization - we can table that for now, in this discussion), is that the webapp coordinates whatever connectionless/shared delivery system is to be used along with the appropriate addressing scheme and address, with the webapp server prior to the switch (or in the setup of the original connection). Without getting too deep in to specific system designs I can say that this does work and can demo the concept pretty soon (I'm implementing a demo now). Re (2), since the webapp creates a specific eventsource object (using SSE as the model), there is a direct thread back to it from the user agent. What is needed for the user agent to deliver only the specific events that the webapp desires, is that there needs to be some filter criteria that is negotiated with the webapp server (or delivery system) e.g. as part of the original eventsource object creation. In OMA Push, we have an Application ID header that is used for this purpose (it can carry any arbitrary value, and be used by the user agent or a local Push Client to filter out events other than those desired). Webapps can also use any arbitrary application-layer data to filter or apply trust to incoming events, but this is a convenient thing to do by a UA or Push Client and that's why we included that in the OMA Push design. Other notification delivery systems probably have similar features. The goal is not however to reference delivery-system specific features directly in the W3C API, but to describe how such app addressability is possible in general, and at most to all generic filter criteria mechanisms to the API (e.g. this header equals that value, or more generically this token is present with that value). Re (3), I think the web authentication system (same-origin policy and CORS) is strong enough for what is needed here. Beyond that, apps can use any high-order security for authentication/authorization tokens to be included in the application data or as headers (in delivery systems that follow the HTTP header+body model, ala OMA Push). There's probably a lot in the above statements that need to be unpacked in more detail. That's why we proposed this for the charter update. We have been involved in Push-based enabler and service design since pre-2000, and with that background I think we have a good foundation to resolve the questions you noted. Thanks, Bryan Sullivan -Original Message- From: Karl Dubost [mailto:ka...@opera.com] Sent: Monday, March 12, 2012 2:04 PM To: SULLIVAN, BRYAN L Cc: Ian Hickson; Stefan Hakansson LK; public-webapps@w3.org Subject: Re: Regarding app notification and wake up Le 9 mars 2012 à 19:43, SULLIVAN, BRYAN L a écrit : This is different from the earlier discussion on extending SSE to connectionless event sources, as there's no assumption the Webapp is running in this case. If the Webapp *is* running, it's within the scope of what we have discussed earlier as SSE extensions (and not technically a wakeup). If I understood the use case, it means that 1. the device is addressable (except for customers with a subscription to a Mobile Operator, not sure how we would do that. Any ideas? Maybe on local network that would be feasible but doesn't answer the use case it seems.) 2. the software is addressable (more than one software able to process a specific request. Think about Opera and Firefox on the same device.) 3. that also requires a strong authentication system I can see the appeal, but I balance it with spam at large scale too. The UX model of SSE is that the user is still initiating the call. Related to the initial mail http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0008 http://bkaj.net/w3c/eventsource-push.html -- Karl Dubost - http://dev.opera.com/ Developer Relations, Opera Software
Re: Regarding app notification and wake up
On Fri, 09 Mar 2012 09:10:19 +0100, Stefan Hakansson LK stefan.lk.hakans...@ericsson.com 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. In the current charter proposal (which is under review at the moment) we have [[[ Server-Sent Events An API for opening an HTTP connection for receiving push notifications from a server in the form of DOM events. The API is designed such that it can be extended to work with other push notification schemes such as Push SMS. ]]] - http://www.w3.org/2012/03/webapps-proposed-charter.html I'm not sure if that is enough, sounds like you would like something more. In which case the best thing is to get people who are interested in developing it to say so, through their review and in this working group. cheers Chaals -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan litt norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Regarding app notification and wake up
Le 9 mars 2012 à 19:43, SULLIVAN, BRYAN L a écrit : This is different from the earlier discussion on extending SSE to connectionless event sources, as there's no assumption the Webapp is running in this case. If the Webapp *is* running, it's within the scope of what we have discussed earlier as SSE extensions (and not technically a wakeup). If I understood the use case, it means that 1. the device is addressable (except for customers with a subscription to a Mobile Operator, not sure how we would do that. Any ideas? Maybe on local network that would be feasible but doesn't answer the use case it seems.) 2. the software is addressable (more than one software able to process a specific request. Think about Opera and Firefox on the same device.) 3. that also requires a strong authentication system I can see the appeal, but I balance it with spam at large scale too. The UX model of SSE is that the user is still initiating the call. Related to the initial mail http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0008 http://bkaj.net/w3c/eventsource-push.html -- Karl Dubost - http://dev.opera.com/ Developer Relations, Opera Software
RE: Regarding app notification and wake up
Karl, excellent questions. Re (1), there are various systems of device addressing in use today, largely dependent upon the notification delivery system. An assumption to start with is that barring any optimizations which enable seamless switching between SSE connections and connectionless delivery (which requires a delivery agent/client on the device, feasible but still an optimization - we can table that for now, in this discussion), is that the webapp coordinates whatever connectionless/shared delivery system is to be used along with the appropriate addressing scheme and address, with the webapp server prior to the switch (or in the setup of the original connection). Without getting too deep in to specific system designs I can say that this does work and can demo the concept pretty soon (I'm implementing a demo now). Re (2), since the webapp creates a specific eventsource object (using SSE as the model), there is a direct thread back to it from the user agent. What is needed for the user agent to deliver only the specific events that the webapp desires, is that there needs to be some filter criteria that is negotiated with the webapp server (or delivery system) e.g. as part of the original eventsource object creation. In OMA Push, we have an Application ID header that is used for this purpose (it can carry any arbitrary value, and be used by the user agent or a local Push Client to filter out events other than those desired). Webapps can also use any arbitrary application-layer data to filter or apply trust to incoming events, but this is a convenient thing to do by a UA or Push Client and that's why we included that in the OMA Push design. Other notification delivery systems probably have similar features. The goal is not however to reference delivery-system specific features directly in the W3C API, but to describe how such app addressability is possible in general, and at most to all generic filter criteria mechanisms to the API (e.g. this header equals that value, or more generically this token is present with that value). Re (3), I think the web authentication system (same-origin policy and CORS) is strong enough for what is needed here. Beyond that, apps can use any high-order security for authentication/authorization tokens to be included in the application data or as headers (in delivery systems that follow the HTTP header+body model, ala OMA Push). There's probably a lot in the above statements that need to be unpacked in more detail. That's why we proposed this for the charter update. We have been involved in Push-based enabler and service design since pre-2000, and with that background I think we have a good foundation to resolve the questions you noted. Thanks, Bryan Sullivan -Original Message- From: Karl Dubost [mailto:ka...@opera.com] Sent: Monday, March 12, 2012 2:04 PM To: SULLIVAN, BRYAN L Cc: Ian Hickson; Stefan Hakansson LK; public-webapps@w3.org Subject: Re: Regarding app notification and wake up Le 9 mars 2012 à 19:43, SULLIVAN, BRYAN L a écrit : This is different from the earlier discussion on extending SSE to connectionless event sources, as there's no assumption the Webapp is running in this case. If the Webapp *is* running, it's within the scope of what we have discussed earlier as SSE extensions (and not technically a wakeup). If I understood the use case, it means that 1. the device is addressable (except for customers with a subscription to a Mobile Operator, not sure how we would do that. Any ideas? Maybe on local network that would be feasible but doesn't answer the use case it seems.) 2. the software is addressable (more than one software able to process a specific request. Think about Opera and Firefox on the same device.) 3. that also requires a strong authentication system I can see the appeal, but I balance it with spam at large scale too. The UX model of SSE is that the user is still initiating the call. Related to the initial mail http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0008 http://bkaj.net/w3c/eventsource-push.html -- Karl Dubost - http://dev.opera.com/ Developer Relations, Opera Software
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/
RE: Regarding app notification and wake up
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:scott.bradley.wil...@gmail.com] Sent: Friday, March 09, 2012 6:35 AM To: Stefan Hakansson LK Cc: public-webapps@w3.org 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/
Re: Regarding app notification and wake up
On Fri, 9 Mar 2012, 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. What exactly do you mean by wake up? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: Regarding app notification and wake up
Ian, Stefan may respond with more detail, but the use cases we submitted for WebRTC consideration describe this as the ability to invoke an application and pass an event to it, whether it is running (or not) at the time of the event reception by the device. By running I mean that the app, or its user agent (in the case of a web app executing under a user agent), are not currently executing on the device, in any state. This wake up and deliver capability may require a multi-step device-internal process, but the overall goal covers both actions. Thanks, Bryan Sullivan -Original Message- From: Ian Hickson [mailto:i...@hixie.ch] Sent: Friday, March 09, 2012 4:09 PM To: Stefan Hakansson LK Cc: public-webapps@w3.org Subject: Re: Regarding app notification and wake up On Fri, 9 Mar 2012, 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. What exactly do you mean by wake up? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: Regarding app notification and wake up
On Sat, 10 Mar 2012, SULLIVAN, BRYAN L wrote: Stefan may respond with more detail, but the use cases we submitted for WebRTC consideration describe this as the ability to invoke an application and pass an event to it, whether it is running (or not) at the time of the event reception by the device. By running I mean that the app, or its user agent (in the case of a web app executing under a user agent), are not currently executing on the device, in any state. This wake up and deliver capability may require a multi-step device-internal process, but the overall goal covers both actions. So basically you're saying you want to remotely cause a Web browser to load a Web page? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: Regarding app notification and wake up
Yes, or more specifically (if this matters) invoke a Webapp, which at some level relates to a page as its root. This is different from the earlier discussion on extending SSE to connectionless event sources, as there's no assumption the Webapp is running in this case. If the Webapp *is* running, it's within the scope of what we have discussed earlier as SSE extensions (and not technically a wakeup). Thanks, Bryan Sullivan -Original Message- From: Ian Hickson [mailto:i...@hixie.ch] Sent: Friday, March 09, 2012 4:39 PM To: SULLIVAN, BRYAN L Cc: Stefan Hakansson LK; public-webapps@w3.org Subject: RE: Regarding app notification and wake up On Sat, 10 Mar 2012, SULLIVAN, BRYAN L wrote: Stefan may respond with more detail, but the use cases we submitted for WebRTC consideration describe this as the ability to invoke an application and pass an event to it, whether it is running (or not) at the time of the event reception by the device. By running I mean that the app, or its user agent (in the case of a web app executing under a user agent), are not currently executing on the device, in any state. This wake up and deliver capability may require a multi-step device-internal process, but the overall goal covers both actions. So basically you're saying you want to remotely cause a Web browser to load a Web page? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
