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" <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