On every system we use today (except the iPhone) a lot of programs want to be daemons -- background tasks that sit around to wait for events or perform certain regular operations. On Windows it seems things are the worst, which is why I wrote before about how Windows needs a master daemon. A master daemon is a single background process that uses a scripting language to perform most of the daemon functions that other programs are asking for. A master daemon will wait for events and fire off more full-fledged processes when they happen. Scripts would allow detection of connection on ports, updated software versions becoming available, input from the user and anything else that becomes popular.

(Unix always had a simple master daemon for internet port connections, called inetd, but today Linux systems tend to be full of always-running deamons.)

Background tasks make a system slow to start up, and take memory. This is becoming most noticed on our new, lower powered devices like smartphones. So much so that Apple made the dramatic decision to not allow applications to run in the background. No multitasking is allowed. This seriously restricts what the iPhone can do, but Apple feels the increase in performance is worth it. It is certainly true that on Windows Mobile (which actually made it hard to terminate a program once you started it running) very quickly bloats down and becomes unusable.

Background tasks are also sucking battery life on phones. On my phone it's easy to leave Google maps running in the background by mistake, and then it will sit there constantly sucking down maps, using the network and quickly draining the battery. I have not tried all phones, but Windows Mobile on my HTC is a complete idiot about battery management. Once you start up the network connection you seem to have to manually take it down, and if you don't you can forget about your battery life. Often is the time you'll pull the phone out to find it warm and draining. I don't know if the other multitasking phones, like the Android, Pre and others have this trouble.

The iPhone's answer is too draconian. I think the answer lies in a good master daemon, where programs can provide scripts in a special language to get the program invoked on various events. Whatever is popular should be quickly added to the daemon if it's not too large. (The daemon itself can be modular so it only keeps in ram what it really needs.)

In particular, the scripts should say how important quick response time is, and whether the woken code will want to use the network. Consider an e-mail program that wants to check for new e-mail every 10 minutes. (Ideally it should have IMAP push but that's another story.)

The master daemon scheduler should realize the mail program doesn't have to connect exactly every 10 minutes, though that is what a background task would do. It doesn't mind if it's off by even a few minutes. So if there are multiple programs that want to wake up and do something every so often, they can be scheduled to only be loaded one or two at a time, to conserve memory and CPU. So the e-mail program might wait a few minutes for something else to complete. In addition, since the e-Mail program wants to use the network, groups of programs that want to use the network could be executed in order (or even, if appropriate, at the same time) so that the phone ends up setting up a network connection (on session based networks) and doing all the network daemons, and then closing it down.

The master daemon could also centralize event notifications coming from the outside. Programs that want to be woken up for such events (such as incoming emails or IMs) could register to be woken up on various events on ports. If the wireless network doesn't support that it might allow notifications to come in via SMS that a new task awaits. When this special SMS comes in, the network connection would be brought up, and the signalled task would run, along with other tasks that want to do a quick check of the network. As much of this logic should be in the daemon script, so that the full program is only woken up if that is truly needed.

The daemon would of course handle all local events (key presses, screen touches) and also events from other sensors, like the GPS (wake me up if we get near hear, or more than 100 meters from there, etc.) It would also detect gestures with the accelerometer. If the user shakes the phone or flips it in a certain way, a program might want to be woken up.

And of course, it should be tied to the existing daemon that handles incoming calls and SMSs. Apps should be able to (if given permission) take control of incoming communications, to improve what the regular phone does.

This system could give the illusion of a full multitasking phone without the weight of it. Yes, loading in an app upon an event might be slightly slower than having it sitting there in ram. But if there is spare ram, it would of course be cached there anyway. An ideal app would let itself be woken up in stages, with a small piece of code loading quickly to give instant UI response, and the real meat loading more slowly if need be.

While our devices are going to get faster, this is not a problem which will entirely go away. The limiting factors in a portable device are mostly based on power, including the power to keep the network radios on. And applications will keep getting bigger the faster our CPUs get and the bigger our memories get. So this approach may have more lifetime than you think.