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.

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

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

* |readyState| should be a DOMString.

* 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.

* 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.

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/

Cheers,
--
Mounir

Received on Friday, 25 May 2012 22:17:30 UTC