RE: Push API draft uploaded

Thanks for the comments. Some responses added as <bryan>

Thanks,
Bryan Sullivan

-----Original Message-----
From: Mounir Lamouri [mailto:mounir@lamouri.fr] 
Sent: Friday, May 25, 2012 3:17 PM
To: public-webapps@w3.org
Subject: Re: Push API draft uploaded

On 05/24/2012 09:14 AM, SULLIVAN, BRYAN L wrote:
> 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/Serices/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.

Hi,

I have a few random comments:

* As far as I understand it, |requestRemotePermission| and
|checkRemotePermission| could be one single method which could be named
something like |getPushServiceUrl|. The only difference between those
two methods is the permission asking part but that should stay as a UA
decision. Given that the method is anyway asynchronous, the UA can do
whatever wanted before sending a result. Showing a permission prompt
could be one of those.

<bryan> I agree that these methods could collapse into one. But as this interface was based upon the Mozilla proposal (https://wiki.mozilla.org/Services/Notifications/Push/API) I would like to get the author's view on the potential to collapse the two methods into one.

* I wonder if it is really useful to have clients requesting a specific
Push service. I totally understand why a user would request to use his
preferred Push service but that is part of the UA. I would tend to think
we should not add that parameter until it's proven to be needed by some
consumer of the API. Adding it would be simple; removing it might not be
an option. Also, allowing a website to chose the Push service might
break the entire idea of decentralization here: you might end up with
most websites requesting to use "push.popularservice.com".

<bryan> If a service is effective and thus popular, why shouldn't it be accessible to developers? Rather than break decentralization, this flexibility enables it IMO, so I think there is a misunderstanding somewhere. To enable some degree of Push service (and thus service provider) flexibility, I have also proposed that we could use Web Intents as a way to allow the user to select the service provider, but if the app has particular requirements (e.g. security or delivery methods/bearers), I see no reason why we should obfuscate the developer intent by making the user play the match maker. The requested service URL also provides means to negotiate additional functionality/options between the app and the Push service directly e.g. as above (e.g. security, delivery methods/bearers, application characteristics, ...).

* I'm not sure why you have a |requestUrl| attribute in PushService. Do
you have any use case for that?

<bryan> The use case is that an app can have multiple Push service requests active at a time, with different URLs. In order to be able to associate each PushService object with a specific set of options or services for example, it needs to know what URL was used when the PushService object was created. The intent is similar to that of EventSource, which has the url attribute for a similar purpose (at least that is how I have used it). And since the checkRemotePermission() method needs to verify the permission for the same URL, it is better to have the resolved form of the URL available as an attribute, so that it's easy to call the checkRemotePermission() method for the right URL (as the absolute URL may have changed since the original resolution).

* |readyState| should be a DOMString.

<bryan> The jury is out on this, AFAICT. It's a short in EventSource and XHR. I was following their lead.

* I guess the idea of |onmessage| is that the PushService instance will
get an event when the backend will push a notification to the webapp.
However, I wonder how you do handle the situation when the application
is actually not being ran. Or should we wait for it to be launched?
Anyhow, coupling the URL request and the event handling at the same
place seems weird.

<bryan> Not at all. This is the way that EventSource works for example (the message handler is overtly associated with the request to a specific service URL). I'm not sure what you mean by "when the application is actually not being ran"... if you mean "when the app is not running", the answer is yes, the app should be started and the event then delivered to it.

* If we want want a |wakeup| attribute, this might need to live in the
manifest as Jose suggested. In general, I wonder if that should be
something the UA requests. I would understand why the UA would ignore
|wakeup = true| but I wouldn't understand why it should always follows
the passed value.

<bryan> The wakeup feature might be turned on by the app through an interface with the user, and used sometimes and others not per the needs of the app and preferences of the user (app managed). If it's in the manifest, it's fixed. I don't believe the UA should ignore the requirements of the app, when the user has given their permission for its operation as needed (both by browsing/installing the app, and overtly by approving Push service use).

For the two last points, maybe using Mozilla's System Message Handler
would help?
See:
https://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/a3c6e4c31d04b663/

<bryan> There are some good ideas there, and certainly for a Web-based OS device such as B2G this would be essential to define if inter-app messaging is to be supported. I expect this will be a topic in the Sysapps WG. I will dig deeper into the post to see what concepts should also be incorporated into this (Push API) proposal.

Cheers,
--
Mounir

Received on Saturday, 26 May 2012 03:08:18 UTC