RE: Push API draft uploaded

Responses inline.

Thanks,
Bryan Sullivan 
-----Original Message-----
From: Mounir Lamouri [mailto:mounir@lamouri.fr] 
Sent: Wednesday, May 30, 2012 2:15 AM
To: public-webapps@w3.org
Subject: Re: Push API draft uploaded

On 05/29/2012 06:13 PM, SULLIVAN, BRYAN L wrote:
>> * 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 do not understand why a concept should be used in this specification
because it is used in Web Intents. And I do not understand why making an
API integrated with Web Intents is good for the Web. Really

<bryan> The concept of a requested service URL is not in this spec because the concept is used in or borrowed from Web Intents. The concept is there because it allows developers the flexibility of Push service provider selection. On its own, it has no dependency upon Web Intents. I mention Web Intents only to illustrate that as an additional potential mechanism, it can be considered as a specific way to get the user involved in the Push service provider selection, if the developer has no preference in the matter.

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

XHR just can't be changed, this is why it is keeping integers instead of
string for errors. I do not know for EventSource. Anyhow, I'm not going
to argue more on that subject.

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

I wasn't clear I think. If you start an application because of a
particular event, the application has no way to know it has been started
because of the event until the event is actually sent. But the event
will be sent at a point during load (or after) and in the meantime, the
application might show a UI as if it was simply started by the user. So
you might have a weird UI flickering where something will be shown and
very quickly will be changed to something else because of the push
notification coming.

<bryan> This is an app design issue that can be overcome, and there is no specific reason that an event should cause a UI change in the app, or a confusing UI change. I believe that app developers will figure out ways to handle this, being analogous to starting an email client and seeing that the inbox starts growing. If the response to an event results in an app behavior that makes sense or that the user is familiar with already, then that will become a normal thing and not confusing to the user.

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

So the user doesn't really give its permission to the app to wakeup the
device but to the app to be able to receive push notifications. Then,
the app is the only one deciding if it will wakeup the device or not.
I'm not a big fan of that approach but I don't really have a better idea
for the moment.

Cheers,
--
Mounir

Received on Thursday, 31 May 2012 23:32:25 UTC