Re: [runtime] Privileged Applications Extensions spec proposal

On Jun 28, 2013, at 9:47 AM, Janusz Majnert <j.majnert@samsung.com>
 wrote:

> On 2013-06-27 22:23, Kostiainen, Anssi wrote:
>> 
>> I think the UA should at least allow the update to be deferred for later if the user so prefers. As currently written, the algorithm will simply "Stop application from running if it is currently running" without asking the user if it is a good time to do so.
>> 
>> For example, I wouldn't be too happy if my browser would close itself without asking me to update itself while I'm working with it.
> 
> Well I would stop using any software that does things like that. Having that in mind, have you ever seen an app store application that downloads updates in the background and stops running apps without user knowingly allowing that?

[Well, no. But I don't typically download badly behaving apps in the first place. I live in my browser ;-)]

I think we have identified two options:

1) Keep applyUpdate(), improve the algorithm to allow the UA to defer applying the update for later.

2) Remove applyUpdate(), leave applying the update up to the implementation, and specify that the UA will install the update only when the application is not running. If an app developer wants to enforce an update in this case, she can invoke exit(). Actually, this would be a good use case for adding relaunch() or reload(), WDYT?

The option 1 gives more control over the app update to the app developer, while the option 2 will mean more consistent update behaviour across apps.

All - which one is the preferred mechanism to you?

>> Should we keep applyUpdate(), I suggest we tune the normative language to make it possible to defer the update for later. When the app is launched the next time, the update would be installed.
> 
> An app store application is capable of checking if an application is currently running (Application.state), so it may choose to defer installation. I think the change you are proposing here is not necessary to build a good app store application and provide good UX. On the other hand it sounds reasonable to allow the UA to make that choice.


I'd prefer to keep this in the UA's control, rather than trusting each app developer to do the Right Thing. Especially considering the non-curated nature of the Web.

The history has shown us that APIs that can be abused, will be abused. Think open() and showModalDialog() for example -- due these APIs most UAs ship with popup blockers enabled by default today.

-Anssi

Received on Friday, 28 June 2013 08:06:51 UTC