RE: Push API draft uploaded

Responses inline.

Thanks,
Bryan Sullivan 
-----Original Message-----
From: Mounir Lamouri [mailto:mounir@lamouri.fr] 
Sent: Tuesday, May 29, 2012 3:06 AM
To: public-webapps@w3.org
Subject: 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.

<bryan> OK, I am open to collapsing these two methods into one, and will update the draft with a proposal for that.

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

<bryan> The concept of service provider selection by the user (in essence the provider of some functionality distributed as Web pages/applications/workers etc) is fundamental to the Web Intents concept, so it seemed natural to me to consider that for this API. I don't think UA's should be exclusively responsible for service provider selection, for this purpose or others. If service providers can be more flexibly integrated through APIs such as Web Intents IMO that is good for the Web.

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

<bryan> But as with EventSource, we won't know if the service URL will be commonly relative, or not. EventSource itself is quite young in terms of adoption, and with CORS there are good reasons why the path *won't* be relative in many cases. But for this API, the purpose of having the attribute is nonetheless the same; when the service URL *is* relative, this helps ensure that the app can verify permission for the URL as earlier resolved. 

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

<bryan> If we can get Webapps resolution on that as a recommended design approach going forward, as I said I am open to this. Perhaps the XHR and EventSource editors can voice an opinion here?

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

<bryan> I'm not sure how it's hard; the Webapp just arranges for Push message delivery when it is invoked, and events are delivered to the object that represents the service arrangement (whether connection-based or connectionless or whatever). I may be missing your counterpoint.

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

<bryan> By navigating to the Webapp (implicitly, in the case that the Webapp had previously been permitted access to Push services by the user), and by accepting the UA's prompt as to whether this app should be allowed to receive Push messages the first time the user navigates to it (explicitly).

Cheers,
--
Mounir

Received on Tuesday, 29 May 2012 16:14:13 UTC