Hi Jose, Thanks for the comments.
Re "the idea is to decouple permissions from APIs": potentially for the Sysapps WG this will be possible, but currently in DAP and in Webapps if the Web security model isn't enough (e.g. same-origin and CORS), then any special considerations are addressed in the API specs themselves. In this case the ability to invoke the app (wakeup) and receive Push messages when the app is offline in general (as in the Mozilla proposal) goes beyond the ability of same-origin and CORS to ensure user protection. Thus the user is prompted at least once. It's not a perfect solution but at least consistent with what has been the approach, and usable until we get to a more robust permissions framework. Re wakeup as part of an App Manifest: this does not yet apply to Web apps in general. It does seem useful to consider in the "Web app manifest" (https://people.mozilla.com/~anarayanan/webapps.html) as proposed to be worked in Webapps, but again that does not apply (or does not have to be used) for all Web apps. I suppose one could make the argument that if you expect to be woken up, the app should be installed, but I think caching also works for that (as described in the spec as "Examples of cases in which webapps should be invokable"). Re "distinguish between registering the interest on receiving push messages and receiving push messages themselves": I am following the Mozilla lead on registering the intent to receive messages, and also going beyond it with the actual reception capability, and there are separate interfaces for the two functions. We don't yet have a generic "intent registration" mechanism for use here (e.g. based upon the API feature URL concept previously proposed for Widgets and leveraged in WAC), and we may approach that again in Sysapps (TBD), but for now I think the APIs need to address both functions. Re "the possibility of having a queue of pending messages": the spec leaves this as a MAY for now: "When a Push message is received, the user agent must deliver the message data via the onmessage handler, if possible. If delivery is not possible, the user agent may discard the message, or may queue it for later delivery." Thanks, Bryan Sullivan -----Original Message----- From: JOSE MANUEL CANTERA FONSECA [mailto:j...@tid.es] Sent: Friday, May 25, 2012 4:36 AM To: SULLIVAN, BRYAN L; public-webapps Subject: Re: Push API draft uploaded I have some comments: I think the idea is to decouple permissions from APIs, making that part of a Security Model, so I don't understand why we are putting here that functionality. Concerning wakeup, etc. I think that should not be part of the API itself but of the App Manifest I think we need to distinguish between registering the interest on receiving push messages and receiving push messages themselves. The current API does not address the possibility of having a queue of pending messages. best El 24/05/12 09:14, "SULLIVAN, BRYAN L" <bs3...@att.com> escribió: >Thanks to the inestimable help of the W3C staff I am now plugged into the >mercurial mainline and have uploaded the first stab at the Push API >http://dvcs.w3.org/hg/push/raw-file/default/index.html > >I incorporated Mozilla's client API ideas in >https://wiki.mozilla.org/Services/Notifications/Push/API as the >"PushManager" interface, and also in the "PushService" interface with >some additions to support a more explicit event model for received >message delivery, derived from Server-Sent Events. > >A lot is still left unsaid, and I will work on examples. > >I also have not addressed the server API aspect that Mozilla mentioned in >their proposal. Like a lot that is left unsaid in their client API >proposal (how does the browser determine what that magic server URL >is...?), the server API is likely related to the specific Push service >that is bound to the API. I am considering the use of Web Intents to >discover and select the Push Service provider that the user wants apps to >use, assuming that we can leave the "backend" details to the intent >provider. I'm not yet sure how the pieces will fit together, how much >needs to be defined, and how my earlier proposal about specific event >source selection and filtering fits into this, but it's a start. > >Thanks, >Bryan Sullivan > > > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx
