- From: Tobie Langel <tobie@fb.com>
- Date: Mon, 19 Mar 2012 17:48:23 +0000
- To: "SULLIVAN, BRYAN L" <bs3131@att.com>, Karl Dubost <karld@opera.com>
- CC: Ian Hickson <ian@hixie.ch>, Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>, "public-webapps@w3.org" <public-webapps@w3.org>
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" <bs3131@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:karld@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 > >
Received on Monday, 19 March 2012 17:49:33 UTC