Add some API for application manager

[Terry, YIN(SWD2-SH-TCT)]

Hi all,

On an FFOS device, when storage is low, there will be a notification about "low-storage",
but no detail information for end-user to know what to do about it.
We need a feature "application manager" to show some actionable data to the user so that
he/she can know which application is eating the disk space.

Therefore, we need some web API to support the feature.
For a detail application, we need:
-stop()--to force stop the application
-isRunning()--to check if the application is running
-clearAppData()--to clear data of an application
-getDataSize()--to calculate the size of an application
For applicationMgmt,
-getRunningApps()

The following is the idl which I add the above apis. Need some advice, thanks.
https://github.com/yinjun/AppManager/commit/e9ddb0728ce1c61d8ba387796c3689f19c418591#gecko

BR
terry

[Fabrice Desre]

Hi Terry,

Thanks for reaching out on this subject.

> Therefore, we need some web API to support the feature.
> For a detail application, we need:
> -stop()--to force stop the application
> -isRunning()--to check if the application is running
> -clearAppData()--to clear data of an application
> -getDataSize()--to calculate the size of an application
> For applicationMgmt,
> -getRunningApps()

stop() is not so simple because of entry points. For instance in gaia
the communications app has 3 "sub-apps": you can launch "dialer",
"contacts" or "ftu". So stop() has to take an entry point parameter,
like launch().

I would also replace isRunning() by a readonly property (eg. "state":
"running | stopped") and remove getRunningApps since you can get that
from getAll() and the state property.

Fabrice
--
Fabrice Desré
b2g team
Mozilla Corporation

[Tim Chien]

On Tue, Aug 27, 2013 at 1:30 PM, Fabrice Desre <fab...@mozilla.com> wrote:
> Hi Terry,
>
> Thanks for reaching out on this subject.
>
>> Therefore, we need some web API to support the feature.
>> For a detail application, we need:
>> -stop()--to force stop the application
>> -isRunning()--to check if the application is running
>> -clearAppData()--to clear data of an application
>> -getDataSize()--to calculate the size of an application
>> For applicationMgmt,
>> -getRunningApps()
>
> stop() is not so simple because of entry points. For instance in gaia
> the communications app has 3 "sub-apps": you can launch "dialer",
> "contacts" or "ftu". So stop() has to take an entry point parameter,
> like launch().
>

I think if stop() merely kill the app process underneath, Gaia System
could handle all that mozbrowsererrror (fatal) events just fine.

Unless you are thinking about routing stop() to Gaia System for it to
identify the iframes and remove them -- I don't think if there is any
benefit coming out of this compare to former approach.

> I would also replace isRunning() by a readonly property (eg. "state":
> "running | stopped") and remove getRunningApps since you can get that
> from getAll() and the state property.
>
> Fabrice
> --
> Fabrice Desré
> b2g team
> Mozilla Corporation

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi



--
Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox
OS, Mozilla Corp. (Taiwan)

[Fernando Jiménez Moreno]

(+Bcc dev-b2g)

Hi Terry!

Thanks for bringing up this topic. There are already some bugs related to this. Check [1], [2] and for low device storage topic in general [3].

I totally agree about the need of this API. However, I think that we might probably keep it a bit simpler :)

>>> Therefore, we need some web API to support the feature.
>>> For a detail application, we need:
>>> -stop()--to force stop the application
>>> -isRunning()--to check if the application is running
>>> -clearAppData()--to clear data of an application
>>> -getDataSize()--to calculate the size of an application
>>> For applicationMgmt,
>>> -getRunningApps()

Correct me if I am wrong please, but I think that you are suggesting to expose "isRunning()" and "stop()" functions so the application which data we want to clear can be stopped (if it is running) before calling "clearAppData()". Am I right? In that case, why not just adding that functionality within the "clearAppData()" implementation? I mean, "clearAppData" should check if the app is running, stop the application in that case and then clear its data. This way we can get rid of "isRunning()" and "stop()".

I agree with Fabrice that "getRunningApps()" is also not needed.

So the API would be like:

partial interface Application {
DOMRequest clearAppData(DOMString type);
DOMRequest getDataSize(DOMString type);
};

I am not sure about the usage of Promise instead of DOMRequest though. I think that we are supposed to start using Promise, but I am not entirely sure that we want to mix DOMRequest and Promise in the same API (we probably don't) instead of migrating the entire API at once. In any case, that's something to be discussed later.

We also probably need to revisit the "type" values that you are suggesting at [4], but I think that's the basic idea.

Thanks!

/ Fernando

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=882098
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=862408
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=861898
[4] https://github.com/yinjun/AppManager/commit/e9ddb0728ce1c61d8ba387796c3689f19c418591#L0R112

[zhiming tang]

Hi,

Thank you so much for your comment on the app manager!

We would first rework the webapi part as follow:

*-getRunningApps()* is a little redundant, we will remove it to keep
simplicity of API.

*-stop()* doesn't work well for the "multi-entrypoint" application now,
only the last launched entrypoint would be removed. We will fix it and
try to let stop() act with entrypoint as parameter.
(btw, we manipulate the iframe instead of process in gecko, that's
partially why we have this problem)

-*isRunning()* will be replace with a read-only attribute, which
indicates the status of the app. (Or it would be better to list the
status per entry points for the app)


B.R.
Tang zhiming

>
> On Tue, Aug 27, 2013 at 1:30 PM, Fabrice Desre<fab...@mozilla.com> wrote:
> > Hi Terry,
> >
> > Thanks for reaching out on this subject.
> >

> >> Therefore, we need some web API to support the feature.
> >> For a detail application, we need:
> >> -stop()--to force stop the application
> >> -isRunning()--to check if the application is running
> >> -clearAppData()--to clear data of an application
> >> -getDataSize()--to calculate the size of an application
> >> For applicationMgmt,
> >> -getRunningApps()
> >

[zhiming tang]

Hi Fernando,

Actually we had an internal discuss on combining stop() into clearData()
before in order to make API simple.
However in my opinion sometime user want to stop application without
clearing the data and that's basic function app manager should afford.
So they are now separated APIs.

Thanks also for pointing out the usage of Promise. Since it's a new
proposal and not get used in the webapi for web apps, I would still
using DOMRequest for now to keep consistency.

I would also like to explain the | type | of data calculating and clearing.
USER_DATA = cookie + localStorage + indexedDB. They are typical "user
data" generated during user is playing with the application. All of them
live in your /data partition.
CACHE stands for app cache or browsing cache which will goes into /cache
partition. That is to say, clearing CACHE doesn't help user to reclaim
any space on your data storage. But user could clear all the "trace"
with clear USER_DATA+CACHE.


B.R.
Tang zhiming

> -------- Original Message --------
> Subject: Re: Add some API for application manager
> Date: Tue, 27 Aug 2013 15:40:07 +0200
> From: Fernando Jiménez Moreno <ferjm...@gmail.com>
> To: Tim Chien <timd...@mozilla.com>
> CC: Fabrice Desre <fab...@mozilla.com>,
> <dev-w...@lists.mozilla.org>, "Terry, YIN(SWD2-SH-TCT)"
> <terr...@tcl.com>
>
>
>
> (+Bcc dev-b2g)
>
> Hi Terry!
>
> Thanks for bringing up this topic. There are already some bugs related to this. Check [1], [2] and for low device storage topic in general [3].
>
> I totally agree about the need of this API. However, I think that we might probably keep it a bit simpler :)
>

> >>> Therefore, we need some web API to support the feature.
> >>> For a detail application, we need:
> >>> -stop()--to force stop the application
> >>> -isRunning()--to check if the application is running
> >>> -clearAppData()--to clear data of an application
> >>> -getDataSize()--to calculate the size of an application
> >>> For applicationMgmt,
> >>> -getRunningApps()
>

[Alive]

Hi,

As Tim had mentioned, why do we need to re-implement |stop application| in gecko?
Do you want to have another app to behave the same role as Gaia System App?

If this is for clearData usage only, we shall use mozSettings (or new API) and let system app to observe the settings change to do the following stop or restart stuff.

I don't think we should dupe the so-called "application manager" in gecko layer because in the long run you would have gaia:system and gecko handle the same thing. It shall be left in gaia.

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi

--

Alive C. Kuo, Front-end Engineer, FirefoxOS, MoCo. Taiwan, Taipei office.
al...@mozilla.com

[Zhiming, TANG(SWD2-SH-TCT)]

Hi Alive,

>If this is for clearData usage only, we shall use mozSettings (or new API) and let system app to observe the settings change to do the following stop or restart stuff.

One concern is about security control. We think mozSettings is very popular permission which you might grant to most applications. But shuting down app is much more sensitive operation which is only available to system and settings app(pre-embeded app). Web API can be strictly controlled per app, till now mozIDOMApplicationMgmt is only available for settings app, so it looks safe for us.

If you would kindly advise some mechanism to access Gaia System securely, we are glad to re-use gaia system, thanks.

B.R.
Tang zhiming
________________________________________
From: Alive [al...@mozilla.com]
Sent: Wednesday, August 28, 2013 5:32 PM
To: Zhiming, TANG(SWD2-SH-TCT)
Cc: ferjm...@gmail.com; dev-w...@lists.mozilla.org; fab...@mozilla.com; Amélie, KONG(SWD2-SH-TCT); Terry, YIN(SWD2-SH-TCT); timd...@mozilla.com

Subject: Re: Add some API for application manager

Hi,

As Tim had mentioned, why do we need to re-implement |stop application| in gecko?
Do you want to have another app to behave the same role as Gaia System App?

If this is for clearData usage only, we shall use mozSettings (or new API) and let system app to observe the settings change to do the following stop or restart stuff.

I don't think we should dupe the so-called "application manager" in gecko layer because in the long run you would have gaia:system and gecko handle the same thing. It shall be left in gaia.

dev-w...@lists.mozilla.org<mailto:dev-w...@lists.mozilla.org>

https://lists.mozilla.org/listinfo/dev-webapi

--
Alive C. Kuo, Front-end Engineer, FirefoxOS, MoCo. Taiwan, Taipei office.

al...@mozilla.com<mailto:al...@mozilla.com>

[Tim Chien]

That's not what I said. I was simply talking about what should Gecko
do when someone called |stop()|, and it is not clear to me from
reading this thread.

I don't really care who will be using these |mozApps.mgmt| API
methods, it's up to each vendor to do what they feel right if they
ship their own front-end. We could however bring this question to
dev-gaia if we want to implement these functionalities in the open
source codebase.

On Wed, Aug 28, 2013 at 5:32 PM, Alive <al...@mozilla.com> wrote:
> Hi,
>
> As Tim had mentioned, why do we need to re-implement |stop application| in
> gecko?
> Do you want to have another app to behave the same role as Gaia System App?
>
> If this is for clearData usage only, we shall use mozSettings (or new API)
> and let system app to observe the settings change to do the following stop
> or restart stuff.
>
> I don't think we should dupe the so-called "application manager" in gecko
> layer because in the long run you would have gaia:system and gecko handle
> the same thing. It shall be left in gaia.
>

> https://lists.mozilla.org/listinfo/dev-webapi
>
>
> --
> Alive C. Kuo, Front-end Engineer, FirefoxOS, MoCo. Taiwan, Taipei office.
> al...@mozilla.com
>
>
>
>

[Alive]

I know the pain of current mozSettings API.
But what we shall do is to improve its security level IMO.

I wonder eventually this needs gaia system support to let gecko knows the running application information, because gecko doesn't know that right now. More clearly gecko doesn't keep a list of running applications. (Gecko forks please correct me if I am wrong.) If you're aware of this, and be ready to patch gaia system app, welcome.

However I tend to:
* Have a new API for clear app data and a new permission for it. (or mozApps permission is enough?)
* Have settings have that permission.
* Have gecko do the app kill/stop automatically instead of calling "app.stop()" from settings app.
* Gecko would notify system app while app is killed now, but there's no info about 'start an app but leave it in background'. Maybe we need this additional event.

I know android has exposed running application info in settings, but to your use case we could put this new feature later. How do you think? Briefly, Do you really need to know running app info in settings right now?

"Zhiming, TANG(SWD2-SH-TCT)" <zhimin...@tcl.com> 於 2013/8/28 下午5:54 寫道：

> Hi Alive,

>
>> If this is for clearData usage only, we shall use mozSettings (or new API) and let system app to observe the settings change to do the following stop or restart stuff.
>

> One concern is about security control. We think mozSettings is very popular permission which you might grant to most applications. But shuting down app is much more sensitive operation which is only available to system and settings app(pre-embeded app). Web API can be strictly controlled per app, till now mozIDOMApplicationMgmt is only available for settings app, so it looks safe for us.
>
> If you would kindly advise some mechanism to access Gaia System securely, we are glad to re-use gaia system, thanks.
>
> B.R.
> Tang zhiming
> ________________________________________
> From: Alive [al...@mozilla.com]
> Sent: Wednesday, August 28, 2013 5:32 PM
> To: Zhiming, TANG(SWD2-SH-TCT)
> Cc: ferjm...@gmail.com; dev-w...@lists.mozilla.org; fab...@mozilla.com; Amélie, KONG(SWD2-SH-TCT); Terry, YIN(SWD2-SH-TCT); timd...@mozilla.com

> Subject: Re: Add some API for application manager
>

> Hi,
>
> As Tim had mentioned, why do we need to re-implement |stop application| in gecko?
> Do you want to have another app to behave the same role as Gaia System App?
>
> If this is for clearData usage only, we shall use mozSettings (or new API) and let system app to observe the settings change to do the following stop or restart stuff.
>
> I don't think we should dupe the so-called "application manager" in gecko layer because in the long run you would have gaia:system and gecko handle the same thing. It shall be left in gaia.
>

> zhiming tang <zhimin...@tcl.com<mailto:zhimin...@tcl.com>> 於 2013/8/28 下午5:18 寫道：
>
> Hi Fernando,
>
> Actually we had an internal discuss on combining stop() into clearData() before in order to make API simple.
> However in my opinion sometime user want to stop application without clearing the data and that's basic function app manager should afford. So they are now separated APIs.
>
> Thanks also for pointing out the usage of Promise. Since it's a new proposal and not get used in the webapi for web apps, I would still using DOMRequest for now to keep consistency.
>
> I would also like to explain the | type | of data calculating and clearing.
> USER_DATA = cookie + localStorage + indexedDB. They are typical "user data" generated during user is playing with the application. All of them live in your /data partition.
> CACHE stands for app cache or browsing cache which will goes into /cache partition. That is to say, clearing CACHE doesn't help user to reclaim any space on your data storage. But user could clear all the "trace" with clear USER_DATA+CACHE.
>
>
> B.R.
> Tang zhiming
> -------- Original Message --------
> Subject: Re: Add some API for application manager
> Date: Tue, 27 Aug 2013 15:40:07 +0200

> From: Fernando Jiménez Moreno <ferjm...@gmail.com<mailto:ferjm...@gmail.com>>
> To: Tim Chien <timd...@mozilla.com<mailto:timd...@mozilla.com>>

> dev-w...@lists.mozilla.org<mailto:dev-w...@lists.mozilla.org>

> https://lists.mozilla.org/listinfo/dev-webapi
>
> --
> Alive C. Kuo, Front-end Engineer, FirefoxOS, MoCo. Taiwan, Taipei office.

> al...@mozilla.com<mailto:al...@mozilla.com>

[Fabrice Desre]

On 08/28/2013 03:07 AM, Tim Chien wrote:
> That's not what I said. I was simply talking about what should Gecko
> do when someone called |stop()|, and it is not clear to me from
> reading this thread.

This is only an implementation detail, which is totally irrelevant in
this discussion. Let's get the API designed first, and decide on the
implementation later.

Fwiw, the general idea is that the webapps backend delegates some
operations to the runtime (which could be b2g, firefox for android,
desktop firefox, webappRT). On b2g we typically use some glue code that
calls into the system app, and I don't see any reason to do anything
different there. To me, the system app is very much part of the platform
actually.

[Fabrice Desre]

On 08/27/2013 06:40 AM, Fernando Jiménez Moreno wrote:
> (+Bcc dev-b2g)
>
> Hi Terry!
>
> Thanks for bringing up this topic. There are already some bugs related to this. Check [1], [2] and for low device storage topic in general [3].
>
> I totally agree about the need of this API. However, I think that we might probably keep it a bit simpler :)
>
>>>> Therefore, we need some web API to support the feature.
>>>> For a detail application, we need:
>>>> -stop()--to force stop the application
>>>> -isRunning()--to check if the application is running
>>>> -clearAppData()--to clear data of an application
>>>> -getDataSize()--to calculate the size of an application
>>>> For applicationMgmt,
>>>> -getRunningApps()
>
> Correct me if I am wrong please, but I think that you are suggesting to expose "isRunning()" and "stop()" functions so the application which data we want to clear can be stopped (if it is running) before calling "clearAppData()". Am I right? In that case, why not just adding that functionality within the "clearAppData()" implementation? I mean, "clearAppData" should check if the app is running, stop the application in that case and then clear its data. This way we can get rid of "isRunning()" and "stop()".

I don't like the idea of magically closing the app when we want to clear
the user data. clearUserData() should just fail if the app is running.

[Fernando Jiménez Moreno]

On 28/08/2013, at 11:18, zhiming tang wrote:

> Hi Fernando,
>
> Actually we had an internal discuss on combining stop() into clearData() before in order to make API simple.
> However in my opinion sometime user want to stop application without clearing the data and that's basic function app manager should afford. So they are now separated APIs.
>

Right! Actually I was only thinking about the specific need of the clearData() functionality, since you started this thread talking about the low storage scenario. For a wider application manager, we'd need the stop() function too. Sorry for the confusion.

> Thanks also for pointing out the usage of Promise. Since it's a new proposal and not get used in the webapi for web apps, I would still using DOMRequest for now to keep consistency.

I'd go with DOMRequest for now too. But I'd like someone from the WebAPI team to confirm that this is what is expected.

> I would also like to explain the | type | of data calculating and clearing.
> USER_DATA = cookie + localStorage + indexedDB. They are typical "user data" generated during user is playing with the application. All of them live in your /data partition.
> CACHE stands for app cache or browsing cache which will goes into /cache partition. That is to say, clearing CACHE doesn't help user to reclaim any space on your data storage. But user could clear all the "trace" with clear USER_DATA+CACHE.

Got it.

I'm just thinking out loud, but should we notify the app about its data being cleared? I'm thinking about an application (let's say a media manager) that stores its data (about media files) in USER_DATA (i.e. indexedDB) and the sdcard (the media files itself). If we clear the data in USER_DATA, the data stored in the sdcard might become orphan. If we notify the app about its data being cleared *before* actually clearing it, the app would be able to completely clear the associated data that is not stored in USER_DATA (the one in the sdcard, in this case). Once the app handles this notification the platform could safely remove the requested data.

Cheers,

/ Fernando

>
> B.R.
> Tang zhiming
>> -------- Original Message --------
>> Subject: Re: Add some API for application manager
>> Date: Tue, 27 Aug 2013 15:40:07 +0200
>> From: Fernando Jiménez Moreno <ferjm...@gmail.com>

>> To: Tim Chien <timd...@mozilla.com>
>> CC: Fabrice Desre <fab...@mozilla.com>, <dev-w...@lists.mozilla.org>, "Terry, YIN(SWD2-SH-TCT)" <terr...@tcl.com>
>>
>> (+Bcc dev-b2g)
>>
>> Hi Terry!
>>
>> Thanks for bringing up this topic. There are already some bugs related to this. Check [1], [2] and for low device storage topic in general [3].
>>
>> I totally agree about the need of this API. However, I think that we might probably keep it a bit simpler :)
>>
>> >>> Therefore, we need some web API to support the feature.
>> >>> For a detail application, we need:
>> >>> -stop()--to force stop the application
>> >>> -isRunning()--to check if the application is running
>> >>> -clearAppData()--to clear data of an application
>> >>> -getDataSize()--to calculate the size of an application
>> >>> For applicationMgmt,
>> >>> -getRunningApps()
>>
>> Correct me if I am wrong please, but I think that you are suggesting to expose "isRunning()" and "stop()" functions so the application which data we want to clear can be stopped (if it is running) before calling "clearAppData()". Am I right? In that case, why not just adding that functionality within the "clearAppData()" implementation? I mean, "clearAppData" should check if the app is running, stop the application in that case and then clear its data. This way we can get rid of "isRunning()" and "stop()".
>>

[Fernando Jiménez Moreno]

On 28/08/2013, at 16:52, Fabrice Desre wrote:

> On 08/27/2013 06:40 AM, Fernando Jiménez Moreno wrote:

>> Correct me if I am wrong please, but I think that you are suggesting to expose "isRunning()" and "stop()" functions so the application which data we want to clear can be stopped (if it is running) before calling "clearAppData()". Am I right? In that case, why not just adding that functionality within the "clearAppData()" implementation? I mean, "clearAppData" should check if the app is running, stop the application in that case and then clear its data. This way we can get rid of "isRunning()" and "stop()".
>

> I don't like the idea of magically closing the app when we want to clear
> the user data. clearUserData() should just fail if the app is running.

Why not? :) We already do that when we have a OOM situation. The app would probably be in the background in any case.

Actually, we might need to close the app from gecko if we want to notify it about the data removal (check my previous email).

In any case, this is also an implementation detail. I already agreed about the need of "stop()" for a wider app manager API.

Cheers!

/ Fernando

[Tim Chien]

Adding the mailing list back.

On Fri, Aug 30, 2013 at 5:47 PM, zhiming tang <zhimin...@tcl.com> wrote:

> >I'm just thinking out loud, but should we notify the app about its data
> being cleared? I'm thinking about an application (let's say a media
> manager) that stores its data (about media files) in USER_DATA (i.e.
> indexedDB) and the sdcard (the media files itself). If we clear the data in
> USER_DATA, the data stored in the sdcard might become orphan. If we notify
> the app about its data being cleared *before* actually clearing it, the app
> would be able to completely clear the associated data that is not stored in
> USER_DATA (the one in the sdcard, in this case). Once the app handles this
> notification the platform could safely remove the requested data.
>

> It's good question. I would first check whether un-install app would leave
> the orphan files on sdcard...

> Jiménez Moreno <ferjm...@gmail.com> <ferjm...@gmail.com> To: Tim
> Chien <timd...@mozilla.com> <timd...@mozilla.com> CC: Fabrice Desre
> <fab...@mozilla.com> <fab...@mozilla.com>,
> <dev-w...@lists.mozilla.org> <dev-w...@lists.mozilla.org>, "Terry,
> YIN(SWD2-SH-TCT)" <terr...@tcl.com> <terr...@tcl.com>

>
> (+Bcc dev-b2g)
>
> Hi Terry!
>
> Thanks for bringing up this topic. There are already some bugs related to this. Check [1], [2] and for low device storage topic in general [3].
>
> I totally agree about the need of this API. However, I think that we might probably keep it a bit simpler :)
>
> >>> Therefore, we need some web API to support the feature.
> >>> For a detail application, we need:
> >>> -stop()--to force stop the application
> >>> -isRunning()--to check if the application is running
> >>> -clearAppData()--to clear data of an application
> >>> -getDataSize()--to calculate the size of an application
> >>> For applicationMgmt,
> >>> -getRunningApps()
>

> Correct me if I am wrong please, but I think that you are suggesting to expose "isRunning()" and "stop()" functions so the application which data we want to clear can be stopped (if it is running) before calling "clearAppData()". Am I right? In that case, why not just adding that functionality within the "clearAppData()" implementation? I mean, "clearAppData" should check if the app is running, stop the application in that case and then clear its data. This way we can get rid of "isRunning()" and "stop()".
>

> I agree with Fabrice that "getRunningApps()" is also not needed.
>
> So the API would be like:
>
> partial interface Application {
> DOMRequest clearAppData(DOMString type);
> DOMRequest getDataSize(DOMString type);
> };
>
> I am not sure about the usage of Promise instead of DOMRequest though. I think that we are supposed to start using Promise, but I am not entirely sure that we want to mix DOMRequest and Promise in the same API (we probably don't) instead of migrating the entire API at once. In any case, that's something to be discussed later.
>
> We also probably need to revisit the "type" values that you are suggesting at [4], but I think that's the basic idea.
>
> Thanks!
>
> / Fernando
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=882098
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=862408
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=861898
> [4] https://github.com/yinjun/AppManager/commit/e9ddb0728ce1c61d8ba387796c3689f19c418591#L0R112
>
>
>
>
>
>
>
>

[Jonas Sicking]

On Aug 16, 2013 2:06 AM, "Terry, YIN(SWD2-SH-TCT)" <terr...@tcl.com>
wrote:

>
> Hi all,
>
> On an FFOS device, when storage is low, there will be a notification
about "low-storage",
> but no detail information for end-user to know what to do about it.
> We need a feature "application manager" to show some actionable data to
the user so that
> he/she can know which application is eating the disk space.
>

> Therefore, we need some web API to support the feature.
> For a detail application, we need:
> -stop()--to force stop the application
> -isRunning()--to check if the application is running
> -clearAppData()--to clear data of an application
> -getDataSize()--to calculate the size of an application
> For applicationMgmt,
> -getRunningApps()

Hi Terry,

Thanks for starting this discussion. I agree that the API that you are
drafting here is very much needed.

There has been some very good feedback from others already, so let me sum
up my opinions.

First off, I think that for security reasons we should stick the stop()
function on the ApplicationMgmt interface.

The reason for this is that API that is available on the App object is
currently available to other application processes since application
processes can access each other's App objects. In many cases doing so
requires hacking gecko, but that's something we in general consider
possible.

So unless there are strong reasons to put stop() on the App object I
propose we put it on ApplicationMgmt.

I also think that stop() should take an argument like stop("normal") or
stop("force") to indicate if we should run shutdown, like on unload,
handlers or not.

I agree with Fabrice that adding a readonly .runState attribute would be
better than adding a isRunning() function.

Other than that the API looks good to me.

Are you interested in working on implementing this API as well?

/ Jonas

[陈国强]

Dear Jonas,

Yes, we are interested in implementing this API.

Best Regards,
Guoqiang CHEN(陈国强）

TCL Corporate Reasearch Xi'an R&D center
Tel: 13002937568
Ext: 029-88320198-8079
E-mail:chengu...@tcl.com

-----邮件原件-----
发件人: dev-webapi
[mailto:dev-webapi-bounces+chenguoqiang=tcl...@lists.mozilla.org] 代表
Jonas Sicking
发送时间: 2013年9月17日星期二 10:10
收件人: Terry, YIN(SWD2-SH-TCT)
抄送: dev-webapi; Fabrice Desré
主题: Re: Add some API for application manager

_______________________________________________
dev-webapi mailing list
dev-w...@lists.mozilla.org

https://lists.mozilla.org/listinfo/dev-webapi