Re: Push API draft uploaded

On 05/26/2012 05:06 AM, SULLIVAN, BRYAN L wrote:
> * 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 wouldn't name the proposal on the wiki page as "Mozilla's proposal".
This wiki is public and what is described is far from being a finished work.
In addition, the wiki page is quite explicit about the existence of
those two methods and the given reasons are quite invalid.

> * 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 don't how this could be related to Web Intents? Picking the service
provider should be up to the UA (using whichever method the UA feels
appropriate). If a website *needs* a specific service provider that
means this API has been a failure so I wouldn't add a parameter that
would help this happen.

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

The resolving part seems quite useless because contrary to EventSource,
it might be pretty uncommon to use a relative path to the push service.
Anyhow, I think this should disappear with the parameter in the methods.
The client shouldn't know which server is used: this is part of the
user's privacy.

> * |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 don't know for XHR but the "new way" is DOMString for multiple
reasons. I believe Ms2ger pointed you to a link which likely explains those.

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

Running a webapp/website then sending an event to it seems a rather hard
task. This is actually what motivated the "System Message Handler" API.

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

I'm not sure I understand how the user would give its permission here.

Cheers,
--
Mounir

Received on Tuesday, 29 May 2012 10:17:19 UTC