- From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
- Date: Thu, 27 Jun 2013 20:23:44 +0000
- To: Janusz Majnert <j.majnert@samsung.com>
- CC: "public-sysapps@w3.org" <public-sysapps@w3.org>
On Jun 27, 2013, at 10:50 AM, Janusz Majnert <j.majnert@samsung.com> wrote: > On 2013-06-27 03:56, Jonas Sicking wrote: >> However applyUpdate() is something that probably possibly shouldn't >> exist at all (other than internally in the runtime implementation). At >> least in FirefoxOS we haven't implemented support for having multiple >> versions of an app installed at the same time. Because of that it's >> important that an update isn't applied as long as the app is running. >> And so applyUpdate() is important that it's only called when it's >> guaranteed that the app isn't running. Something which can't be >> guaranteed as long as the applyUpdate() function is exposed. > > I don't understand how it is a problem that an application is running during an update? Isn't it the "industy standard" to terminate an app before an update takes place (or make a user terminate it beforehand). Applications can detect being shut down (via the onterminate handler) at which point they do all the stuff that they would if the user shut them down manually or if the system decided to close them (Android does something like that). 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. 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. WDYT? -Anssi
Received on Thursday, 27 June 2013 20:24:31 UTC