Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Background services for web applications

1,631 views
Skip to first unread message

Mounir Lamouri

unread,
Mar 18, 2012, 11:39:12 AM3/18/12
to dev-w...@lists.mozilla.org
Hi,

This is a problem the WebAPI team talked about when it was created last
summer but I have the feeling we never came back on that subject since
then and B2G seems to be in a state where this is soon going to be a
problem we will have to solve.

== What we need to solve ==

Right now, IIUIC, applications in B2G are whether opened or closed. That
means if you open the Music app, you will see the UI, you will be able
to play music and from the Task Manager, you will be able to kill the
app. Very likely, at some point, we will make the Task Manager killing
apps automatically depending on CPU usage, memory usage and
foreground/background status (IOW, a background app taking too much
CPU/memory might be killed). With that scenario, the Music app might be
killed quickly because very likely playing an audio file will take a
fair amount of CPU and memory.

Another issue is about events handling. When the app is in foreground,
events handling is trivial but when the app is in background, we can't
guarantee how long the app is going to stay alive. Thus, the application
might miss some events but some applications will not be able to accept
this situation. For example, SMS apps are rarely open all the time but
all users will hope to get a notification when an SMS is received,
whether the application is alive or not.
A very similar issue is about apps that do polling or wait for push
notifications like an email application or a twitter client. Those apps,
if killed when in the background will not work as expected.

Finally, the last problem I see is applications that need to be open
when the phone starts. Most of those applications will be applications
that need to handle events or do polling in the background. For example,
no one wants to need to open his/her SMS application to be able to
receive SMS'. The same way, if I have an email client on my phone, I'm
assuming it will tell me if I get new messages, without me opening it
explicitly [1].

So, the problems we have here are the following:
1. being able to use CPU/Memory without being killed (too aggresively);
2. being able to catch events/do work even if the app is killed;
3. being able to run an application at startup.

== How to solve these problems? ==

There are multiple ways to solve these problems. Some are unlikely to
happen. Some might be considered.

First of all, the trivial answer to this is to say that we never kill an
application unless the user explicitly ask for that. It will solve
problems 1 and 2 but not 3 and it might create a crappy experience for
the user.

We could rely on applications being clever and use visibility change
events. That way, application A that go background could just hide its
UI thus take less memory and go in a mode that will only catch specific
events. Doing this might help application A to not be killed too
quickly. That solution only solves problem 2 and it's flaky because the
app might still be killed. Given that it is requiring applications to
have a clever behavior and it is not solving most of the problems, that
solution doesn't seem to be a good idea.

The last solution I see is for an application to say "this is a service
I want to be run is background, please don't kill it". Those services
will be privileged by the Task Manager and will only be killed in
extreme situations. That way, applications will be able to run in
background some stuff like polling or music playing if needed. They will
also be able to catch some events in those services. The service will
then be able to open the main application. For example, an SMS
application will have a service that will listen for WebSMS events. If
an SMS is received, the service will create a notification and if the
user clicks on the notification, the SMS application will be put in
foreground, whether it was opened or closed. The same way, if a phone
call is received, a service might be able to bring up the phone app UI.
This should solve problems 1 and 2.
Now, we need to be able to say if those services have to be run on
startup. I guess we could use the Open Web Apps manifest for that. When
installing an application, if the manifest mentions a service to be run
on startup, the system will first run it and make sure it's always
launched on startup. That way, an SMS application will never miss an SMS
and users will always get email notifications even if they did not open
the email app.


This proposal is not going into details on purpose. The idea is to first
make sure there is an agreement that the problems listed are real
problems and that the solution mentioned gets a consensus. If this
agreement is reached, I will work on the implementation details like how
to declare a service, how to run it from the app, how to open the app
from the service, how to make sure a service isn't used to cheat the
Task Manager and use large amount of CPU in background, etc...

So, as usual, I'm waiting for feedback.

[1] You could argue that on desktop you have to open your client but on
a phone, the limit between an opened and a closed application is less
clear: users have no simple way to know if application A is open at a
given time.

Cheers,
--
Mounir

Jim Straus

unread,
Mar 18, 2012, 3:58:32 PM3/18/12
to Mounir Lamouri, dev-w...@lists.mozilla.org
On a related note, what about purely background services? As an example, Wifarer has recently started rolling out in-venue navigation (i.e. in a mall or stadium). It is possible that they could decide to extend the geo-location services with a new data source. Is this allowed? Can they do it within the scope below? Given the discussion below, what happens if they do end up being closed?
Also, are apps given notice that they are bing closed? I would hate to take a phone call and have my navigation app be silently closed so I don't get any more prompts to turn left at the next road. If it gets a closing message it can either do something to keep from getting closed or at least post a notification that it was going away so I could re-launch it. I also suspect that apps will need a closing message so that they can be sure to flush their data to storage.
> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi

Mounir Lamouri

unread,
Mar 19, 2012, 12:41:54 PM3/19/12
to dev-w...@lists.mozilla.org
On 03/18/2012 08:58 PM, Jim Straus wrote:
> On a related note, what about purely background services? As an example, Wifarer has recently started rolling out in-venue navigation (i.e. in a mall or stadium). It is possible that they could decide to extend the geo-location services with a new data source. Is this allowed? Can they do it within the scope below? Given the discussion below, what happens if they do end up being closed?
> Also, are apps given notice that they are bing closed? I would hate to take a phone call and have my navigation app be silently closed so I don't get any more prompts to turn left at the next road. If it gets a closing message it can either do something to keep from getting closed or at least post a notification that it was going away so I could re-launch it. I also suspect that apps will need a closing message so that they can be sure to flush their data to storage.

I don't know if B2G will allow an app to provide geolocation services.
If that was the case, depending on the API the app could be opened when
the geolocation is needed and closed after or a service might stay alive
and give information when required.

Regarding navigation app being silently closed, it's exactly in the
context of that proposal: the UI could be closed but all the current
information should stay alive in a service so you can go back to your
navigation after your call even if you happened to be short in memory.

In addition, I believe when the Task Manager will be able to kill
applications automatically based on CPU/memory usage, an event will be
sent to the applications so they will be able to correctly shutdown but
that's completely orthogonal to that discussion I believe.

--
Mounir

lkcl

unread,
Mar 28, 2012, 2:14:34 PM3/28/12
to mozilla-d...@lists.mozilla.org, Jim Straus, ptheriault, Mounir Lamouri
On Mar 18, 4:39 pm, Mounir Lamouri <mou...@lamouri.fr> wrote:
> Hi,
>
> This is a problem the WebAPI team talked about when it was created last
> summer but I have the feeling we never came back on that subject since
> then and B2G seems to be in a state where this is soon going to be a
> problem we will have to solve.
>
> == What we need to solve ==
>
> Right now, IIUIC, applications in B2G are whether opened or closed. That
> means if you open the Music app, you will see the UI, you will be able
> to play music and from the Task Manager, you will be able to kill the
> app. Very likely, at some point, we will make the Task Manager killing
> apps automatically depending on CPU usage, memory usage and
> foreground/backgroundstatus (IOW, abackgroundapp taking too much
> CPU/memory might be killed). With that scenario, the Music app might be
> killed quickly because very likely playing an audio file will take a
> fair amount of CPU and memory.
>
> Another issue is about events handling. When the app is in foreground,
> events handling is trivial but when the app is inbackground, we can't
> guarantee how long the app is going to stay alive. Thus, the application
> might miss some events but some applications will not be able to accept
> this situation. For example, SMS apps are rarely open all the time but
> all users will hope to get a notification when an SMS is received,
> whether the application is alive or not.

yes - this is why i recommended the use of JSONRPC for the purpose
which WebAPIs are presently being put to.

apart from anything, a) the separate executable means that security
is better. b) you stand a chance of being able to use a standard web
browser to test services, perhaps even design B2G to work with *any*
standard web browser (which i understand is one of the goals).

> A very similar issue is about apps that do polling or wait for push
> notifications like an email application or a twitter client. Those apps,
> if killed when in thebackgroundwill not work as expected.

if JSONRPC (or other AJAX technique) is used, you can simply increase
the number of AJAX connections that are allowed, and then use one each
on a blocking query, in place of polling.

l.

Chris Jones

unread,
Mar 29, 2012, 11:54:18 PM3/29/12
to Mounir Lamouri, dev-w...@lists.mozilla.org
If I understand correctly, you're proposing to
- add a permission/attribute that "pins" apps when they go to background, which makes them "more protected" than unpinned apps when memory gets low
- add a permission/attribute to auto-launch some apps on startup

If that's the case, then I like what you're proposing. This in fact quite easy to implement when delegated to a "userspace" app manager. We can almost trivially prototype this in gaia.

Cheers,
Chris

----- Original Message -----
> From: "Mounir Lamouri" <mou...@lamouri.fr>
> To: dev-w...@lists.mozilla.org
> Sent: Sunday, March 18, 2012 8:39:12 AM
> Subject: Background services for web applications
>
> Hi,
>
> This is a problem the WebAPI team talked about when it was created
> last
> summer but I have the feeling we never came back on that subject
> since
> then and B2G seems to be in a state where this is soon going to be a
> problem we will have to solve.
>
> == What we need to solve ==
>
> Right now, IIUIC, applications in B2G are whether opened or closed.
> That
> means if you open the Music app, you will see the UI, you will be
> able
> to play music and from the Task Manager, you will be able to kill the
> app. Very likely, at some point, we will make the Task Manager
> killing
> apps automatically depending on CPU usage, memory usage and
> foreground/background status (IOW, a background app taking too much
> CPU/memory might be killed). With that scenario, the Music app might
> be
> killed quickly because very likely playing an audio file will take a
> fair amount of CPU and memory.
>
> Another issue is about events handling. When the app is in
> foreground,
> events handling is trivial but when the app is in background, we
> can't
> guarantee how long the app is going to stay alive. Thus, the
> application
> might miss some events but some applications will not be able to
> accept
> this situation. For example, SMS apps are rarely open all the time
> but
> all users will hope to get a notification when an SMS is received,
> whether the application is alive or not.
> A very similar issue is about apps that do polling or wait for push
> notifications like an email application or a twitter client. Those
> apps,

JOSE MANUEL CANTERA FONSECA

unread,
Mar 30, 2012, 7:55:13 AM3/30/12
to Mounir Lamouri, dev-w...@lists.mozilla.org


El 18/03/12 16:39, "Mounir Lamouri" <mou...@lamouri.fr> escribió:

>
>
>The last solution I see is for an application to say "this is a service
>I want to be run is background, please don't kill it". Those services
>will be privileged by the Task Manager and will only be killed in
>extreme situations.

Exactly. This is the solution We like more.

One idea would be that these services could be implemented as Web Workers,
although some of them would be "persistent web workers" in the sense that
even if the application UI is closed the Worker keeps running.

>That way, applications will be able to run in
>background some stuff like polling or music playing if needed. They will
>also be able to catch some events in those services. The service will
>then be able to open the main application. For example, an SMS
>application will have a service that will listen for WebSMS events. If
>an SMS is received, the service will create a notification and if the
>user clicks on the notification, the SMS application will be put in
>foreground, whether it was opened or closed. The same way, if a phone
>call is received, a service might be able to bring up the phone app UI.
>This should solve problems 1 and 2.
>Now, we need to be able to say if those services have to be run on
>startup. I guess we could use the Open Web Apps manifest for that. When
>installing an application, if the manifest mentions a service to be run
>on startup, the system will first run it and make sure it's always
>launched on startup.

I like he idea of using the Manifest for this purpose.

>That way, an SMS application will never miss an SMS
>and users will always get email notifications even if they did not open
>the email app.
>
>
>This proposal is not going into details on purpose. The idea is to first
>make sure there is an agreement that the problems listed are real
>problems and that the solution mentioned gets a consensus. If this
>agreement is reached, I will work on the implementation details like how
>to declare a service, how to run it from the app, how to open the app
>from the service, how to make sure a service isn't used to cheat the
>Task Manager and use large amount of CPU in background, etc...
>
>So, as usual, I'm waiting for feedback.

Positive on our side and happy to contribute to the technical spec of
something along the lines you are suggesting above.

>
>[1] You could argue that on desktop you have to open your client but on
>a phone, the limit between an opened and a closed application is less
>clear: users have no simple way to know if application A is open at a
>given time.
>
>Cheers,
>--
>Mounir
>_______________________________________________
>dev-webapi mailing list
>dev-w...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-webapi


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Mounir Lamouri

unread,
Mar 30, 2012, 12:47:52 PM3/30/12
to dev-w...@lists.mozilla.org
On 03/29/2012 08:54 PM, Chris Jones wrote:
> If I understand correctly, you're proposing to
> - add a permission/attribute that "pins" apps when they go to background, which makes them "more protected" than unpinned apps when memory gets low
> - add a permission/attribute to auto-launch some apps on startup

That might be a way to implement it but I was more thinking of a second
app that would have those special permission. For example, the SMS app
would have a SMSService app with it that would have that permission and
would be able to speak with the SMS app.

I guess both solutions would have pros and cons but are quite close.

--
Mounir

mha...@gmail.com

unread,
Mar 28, 2012, 2:15:06 PM3/28/12
to mozilla-d...@lists.mozilla.org, dev-w...@lists.mozilla.org
2 cents:

On the resource consumption question, it's useful to maintain a distinction between user-facing and background resources. When memory gets tight, it would be good to reclaim a window belonging to an app (presumably releasing images, DOM trees, and so forth) before we shutdown a background service (which might just be running a geolocation handler, or waiting for traffic on a Websocket).

So that argues in some form for the "please run this as a background service" idea, I think. Your description sounds about right.

In practice, this would mean that apps have a "fixed" memory portion, which can't be released without terminating, and a "variable" portion, which depends on recent user interaction. That's not a terrible model, and would be somewhat understandable to users. But background services of any sort tend to be "invisible", and we'd have that problem here.

On the "run this service at startup" question - which I think is broadly useful for IM, email, social networking, and many other apps - we need to be aware of the impact on memory and battery from these services, which could be significant (lots of grumbling from iOS users in recent years on this point).

I've been experimenting a bit with the "headless background worker running a JS on behalf of a webapp" for the Social experiment - and it feels good. The patterns feel webby and expressive; each user-facing window can get a reference to the window and post messages back and forth. You can see the sandbox hackery here: https://github.com/mozilla/socialapi-dev/blob/master/lib/frameworker.js

m

mha...@gmail.com

unread,
Mar 28, 2012, 2:15:06 PM3/28/12
to mozilla.d...@googlegroups.com, dev-w...@lists.mozilla.org

Mark Hammond

unread,
Apr 2, 2012, 2:10:47 AM4/2/12
to mozilla-d...@lists.mozilla.org, dev-w...@lists.mozilla.org
On 29/03/2012 5:15 AM, mha...@gmail.com wrote:
....

> I've been experimenting a bit with the "headless background worker
> running a JS on behalf of a webapp" for the Social experiment - and
> it feels good. The patterns feel webby and expressive; each
> user-facing window can get a reference to the window and post
> messages back and forth. You can see the sandbox hackery here:
> https://github.com/mozilla/socialapi-dev/blob/master/lib/frameworker.js

FWIW, the frameworker code mentioned by Mike has intentionally attempted
to expose the same interface as a SharedWorker. One of the main
limitations in the frameworker model is that it runs on the main thread,
so blocking operations would be a serious problem; fortunately the code
we need to use in the "worker" is all async, so we don't hit this problem.

Gecko has DedicatedWorkers, and these could be abused to implement a
kind-of SharedWorker, but the big problem is that the worker
implementation doesn't expose things the spec says it should, like
WebSockets etc, nor other things not mentioned in the spec but probably
necessary anyway (like FileReader, Blob, etc). I'd expect that for use
in this context there would be many more things that need to be exposed.

tl;dr - +1 to SharedWorkers for this use-case, although it seems
unlikely they will be a practical option for some time yet...

Mark

Mark Hammond

unread,
Apr 2, 2012, 2:10:47 AM4/2/12
to mozilla-d...@lists.mozilla.org, dev-w...@lists.mozilla.org
On 29/03/2012 5:15 AM, mha...@gmail.com wrote:
....

> I've been experimenting a bit with the "headless background worker
> running a JS on behalf of a webapp" for the Social experiment - and
> it feels good. The patterns feel webby and expressive; each
> user-facing window can get a reference to the window and post
> messages back and forth. You can see the sandbox hackery here:
> https://github.com/mozilla/socialapi-dev/blob/master/lib/frameworker.js

Mark Hammond

unread,
Apr 2, 2012, 2:10:47 AM4/2/12
to dev-w...@lists.mozilla.org
On 29/03/2012 5:15 AM, mha...@gmail.com wrote:
...

> I've been experimenting a bit with the "headless background worker
> running a JS on behalf of a webapp" for the Social experiment - and
> it feels good. The patterns feel webby and expressive; each
> user-facing window can get a reference to the window and post
> messages back and forth. You can see the sandbox hackery here:
> https://github.com/mozilla/socialapi-dev/blob/master/lib/frameworker.js

Vivien

unread,
Apr 12, 2012, 6:43:11 AM4/12/12
to Mounir Lamouri, dev-w...@lists.mozilla.org
The way it is prototyped in Gaia right now (in a coming pull request) is:
- manifest can contains a 'background_page' field that points to an url
- when the homescreen starts it reads the manifest and launch all the
background_pages urls into an invisible iframe.
- the code in the iframe can do whatever it wants without any
WebWorkers limitations, like using all the navigator APIs, etc. The
permission for the 'service' is the same as the permissions given for
the 'main' application.
- the service can open the main application by using
navigator.mozApps.mgtm.getSelf().launch(). (maybe we need a way to
specify parameters to the launch function)

So as far as I understand this is similar to what you propose.

JOSE MANUEL CANTERA FONSECA

unread,
Apr 12, 2012, 8:00:05 AM4/12/12
to Vivien, dev-w...@lists.mozilla.org
El 12/04/12 12:43, "Vivien" <2...@vingtetun.org> escribió:

>
>The way it is prototyped in Gaia right now (in a coming pull request) is:
> - manifest can contains a 'background_page' field that points to an url
> - when the homescreen starts it reads the manifest and launch all the
>background_pages urls into an invisible iframe.
> - the code in the iframe can do whatever it wants without any
>WebWorkers limitations, like using all the navigator APIs, etc. The
>permission for the 'service' is the same as the permissions given for
>the 'main' application.
> - the service can open the main application by using
>navigator.mozApps.mgtm.getSelf().launch(). (maybe we need a way to
>specify parameters to the launch function)
>
>So as far as I understand this is similar to what you propose.

This mechanism seems to be a hack but not a solution for a final product.
In addition it seems you want to continue increasing the intelligence of
the Homescreen and I think that's not the way to go.

Vivien

unread,
Apr 12, 2012, 10:11:30 AM4/12/12
to JOSE MANUEL CANTERA FONSECA, dev-webapi@lists.mozilla.org >> "dev-webapi@lists.mozilla.org"
On 12/04/2012 05:00, JOSE MANUEL CANTERA FONSECA wrote:
> El 12/04/12 12:43, "Vivien" <2...@vingtetun.org> escribió:
>
>> The way it is prototyped in Gaia right now (in a coming pull request) is:
>> - manifest can contains a 'background_page' field that points to an url
>> - when the homescreen starts it reads the manifest and launch all the
>> background_pages urls into an invisible iframe.
>> - the code in the iframe can do whatever it wants without any
>> WebWorkers limitations, like using all the navigator APIs, etc. The
>> permission for the 'service' is the same as the permissions given for
>> the 'main' application.
>> - the service can open the main application by using
>> navigator.mozApps.mgtm.getSelf().launch(). (maybe we need a way to
>> specify parameters to the launch function)
>>
>> So as far as I understand this is similar to what you propose.
> This mechanism seems to be a hack but not a solution for a final product.


IMHO, As long as it is possible to resolve a problem without having
additional APIs that seems reasonable to me. If something can't be
solved by the existing APIs, I agree that a new one should be created.

This prototype is a web based solution that does not require any
additional APIs and allow Gaia to experiment and see what is missing
until there is a proper solution. But this prototype seems to cover 1.,
2. and 3.
The main question is: What are the limitations of this solution and what
can be provided by background service API that will not be provided by
this solution?

The service can be launched when the application is first installed even
without running the application.
The service can be started when the front-end start and restart with it.
It is possible to kill the service if there is a memory pressure event
at some point (I'm not aware of such event btw) by simply removing the
frame from the dom.
The service runs in the same thread as the homescreen and can spawn
workers if it needs to do any intensive computing tasks.

The background page runs into its own scope and have access to all the
dom/js APIs and share the same origin/permissions than the application
it comes from. So both the service and the application can share data
(via indexedDB for example).
The service can no touch the scope of any other apps/services.


> In addition it seems you want to continue increasing the intelligence of
> the Homescreen and I think that's not the way to go.

This is a very different discussion but about the intelligence of the
homescreen, I will be happy to split its brain into more modular pieces
and services are something that goes into this direction.

For now the homescreen has always be the entry point of Gaia but it is
possible to imagine starting on $GAIA/index.html and let this start page
manages all the windows (iframes) and services itself. It can start the
homescreen (ideally via an intent) that will end up beeing a simple
application to launch other applications using mozApps.launch(). It can
also starts other system services to manage the brightness for example.
That will make the homescreen application much easier to replace without
touching the functionalities of the system itself.

JOSE MANUEL CANTERA FONSECA

unread,
Apr 12, 2012, 10:46:39 AM4/12/12
to Vivien, dev-webapi@lists.mozilla.org >> "dev-webapi@lists.mozilla.org"
El 12/04/12 16:11, "Vivien" <2...@vingtetun.org> escribió:

>On 12/04/2012 05:00, JOSE MANUEL CANTERA FONSECA wrote:
>> El 12/04/12 12:43, "Vivien" <2...@vingtetun.org> escribió:
>>
>>> The way it is prototyped in Gaia right now (in a coming pull request)
>>>is:
>>> - manifest can contains a 'background_page' field that points to an
>>>url
>>> - when the homescreen starts it reads the manifest and launch all the
>>> background_pages urls into an invisible iframe.
>>> - the code in the iframe can do whatever it wants without any
>>> WebWorkers limitations, like using all the navigator APIs, etc. The
>>> permission for the 'service' is the same as the permissions given for
>>> the 'main' application.
>>> - the service can open the main application by using
>>> navigator.mozApps.mgtm.getSelf().launch(). (maybe we need a way to
>>> specify parameters to the launch function)
>>>
>>> So as far as I understand this is similar to what you propose.
>> This mechanism seems to be a hack but not a solution for a final
>>product.
>
>
>IMHO, As long as it is possible to resolve a problem without having
>additional APIs that seems reasonable to me. If something can't be
>solved by the existing APIs, I agree that a new one should be created.

I agree but maybe we don't need a new API or the API could be trivial

>
>This prototype is a web based solution that does not require any
>additional APIs and allow Gaia to experiment and see what is missing
>until there is a proper solution. But this prototype seems to cover 1.,
>2. and 3.
>The main question is: What are the limitations of this solution and what
>can be provided by background service API that will not be provided by
>this solution?

It would be nice that B2G code and not Gaia / OWD code deals with the
problem of starting the background service using the zero-width iframe or
other mechanism.

>
>The service can be launched when the application is first installed even
>without running the application.

I agree and I think this reinforce my previous point. That's something to
solve at platform level but not at the App Level

>The service can be started when the front-end start and restart with it.
>It is possible to kill the service if there is a memory pressure event
>at some point (I'm not aware of such event btw) by simply removing the
>frame from the dom.

I think that's something the platform should take care of

>The service runs in the same thread as the homescreen and can spawn
>workers if it needs to do any intensive computing tasks.

I think it would be better if the service could run on its own thread

>
>The background page runs into its own scope and have access to all the
>dom/js APIs and share the same origin/permissions than the application
>it comes from. So both the service and the application can share data
>(via indexedDB for example).
>The service can no touch the scope of any other apps/services.

I agree with this approach and it is the way to go

>
>
>> In addition it seems you want to continue increasing the intelligence of
>> the Homescreen and I think that's not the way to go.
>
>This is a very different discussion but about the intelligence of the
>homescreen, I will be happy to split its brain into more modular pieces
>and services are something that goes into this direction.

Sure

>
>For now the homescreen has always be the entry point of Gaia but it is
>possible to imagine starting on $GAIA/index.html and let this start page
>manages all the windows (iframes) and services itself. It can start the
>homescreen (ideally via an intent) that will end up beeing a simple
>application to launch other applications using mozApps.launch(). It can
>also starts other system services to manage the brightness for example.
>That will make the homescreen application much easier to replace without
>touching the functionalities of the system itself.

Agreed and that's the direction OWD is currently evolving ...

Mounir Lamouri

unread,
Apr 12, 2012, 11:14:23 AM4/12/12
to dev-w...@lists.mozilla.org
On 04/12/2012 12:43 PM, Vivien wrote:
> The way it is prototyped in Gaia right now (in a coming pull request) is:
> - manifest can contains a 'background_page' field that points to an url
> - when the homescreen starts it reads the manifest and launch all the
> background_pages urls into an invisible iframe.
> - the code in the iframe can do whatever it wants without any
> WebWorkers limitations, like using all the navigator APIs, etc. The
> permission for the 'service' is the same as the permissions given for
> the 'main' application.
> - the service can open the main application by using
> navigator.mozApps.mgtm.getSelf().launch(). (maybe we need a way to
> specify parameters to the launch function)
>
> So as far as I understand this is similar to what you propose.

Except that we might want to limit what those background services can do.

--
Mounir

rstr...@rf-tp.com

unread,
Nov 6, 2013, 9:52:48 AM11/6/13
to
On webOS we faced the same issue of background services, which is a different issue from applications continuing to run when not in the foreground.
The webOS solution involved using node.js to run JavaScript services:
https://developer.palm.com/content/api/dev-guide/js-services/overview.html#javascript-for-services

A good example is an email listener service, which periodically checks for new emails and brings them down when found. This removes this functionality from the UX email application and means you don't need the UX-related overheads when providing a background fetch capability.

One can even go the extra yard and make the service dynamic, only loading it briefly to perform its functionality, either based on a timer or triggered by some system event (ex: incoming SMS).

Using node.js (http://en.wikipedia.org/wiki/Node.js) isn't the correct solution for Firefox OS, but is it architecturally feasible to provide a generally similar capability using SpiderMonkey?

Roger Stringer
0 new messages