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
