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
