ubuntu-phone team mailing list archive

[Rodney Dawes <rodney.dawes@xxxxxxxxxxxxx>]

On Thu, 2014-06-26 at 08:08 +0200, Thomas Voß wrote:
> Hmmm, I see some problems here: I don't think a user starting a
> torrent app on the phone is a strong indication of the user wanting to
> waste battery life and his/her cellular data plan. I think the user
> can rightly expect the system to transparently take care of scarce
> system resources like:
> 
>   * power
>   * cpu cycles
>   * gpu cycles
>   * memory

And yet my laptop still gets 6+ hours of battery life, despite it being
an i7 CPU with 8GB of RAM and a 1080p screen. We still need to care
about power management and wasting of CPU/memory on these platforms as
well.

There's also the problem of convergence and how this will function on
the "Internet of Things" devices, where every app is a background
process that needs to run forever (like apache and dnsmasq). There is no
foreground there. Or are we going to re-implement inetd to manage
whether those services are running or not? 

> On top, I don't think that each and every single app out there
> requires sophisticated background processing to be immediately useful
> to the user. The entire conversation in this thread focuses on that
> one part of the app lifecycle and we spent quite some time and thought
> to present a solution that keeps *most* users and *most* developers
> happy. On top, the presented solution of system-provided services is
> meant to grow over time based on the feedback we receive from users
> and developers, and we can get started adjusting/identifying services
> right now.

Nobody is saying every single app needs sophisticated background
processing to be useful to the user. However, the ones I want to write,
do in fact, need it. Is there any actual documentation on how this
magical system services plan will actually work when it arrives at some
arbitrary point in the future? I've seen NO documentation linked in this
thread about it, but there has been plenty of claim to its greatness.
How can I actually see documentation of how it is supposed to work, and
provide feedback on it to make it better for all developers?

> The other point I want to make: Being strict about the app lifecycle
> is surely difficult and takes time and thought. But it allows us to
> evolve the platform. Along that lines, just opening up the world to
> apps to do whatever they want is not maintainable over time as you
> usually cannot take back any sort of functionality that you once
> committed to.

While we surely cannot be too lenient on app confinement, there is such
a thing as being too strict. Just ask anyone who has ever raised a
teenager. We need proper balance, and right now the use of STOP/CONT
signals to pause/resume an app and prevent it from processing feels like
a workaround to bad UX (it's currently incredibly hard to actually kill
apps on Ubuntu touch) and the use of qmlscene as a production service
(it's only meant to be a development tool).