ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On Thu, Jun 26, 2014 at 3:41 PM, Rodney Dawes
<rodney.dawes@xxxxxxxxxxxxx> wrote:
> 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.
>

Sure, and we can easily do so by adjusting the lifecycle policy for
different usage scenarios. The key points are:

  * Have a well-defined state machine that models the different states
and describe properties and limitations of each state.
  * Define a set of lifecycle policies depending on usage scenario
(mobile device, unplugged or laptop computer)

I assumed that you know:

https://docs.google.com/a/canonical.com/document/d/1ij8RtPsR_eYMW3mys8Gu1Y2CVFZpjXdMpdIjIGZ1SCA/edit#heading=h.28drra4u9knx

given that the document has been around for quite some time now, and
has been referenced multiple times in other mail threads on this list.
It might not contain all of the details you are after, but it gives a
very good overview of the design that we implemented. There are also
multiple UOS sessions available from youtube. Anyway: I'm happy to
iterate on the document and adjust it if concrete points are missing.


> 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?
>

Well, IoT is an entirely different usage scenario and as such
justifies a different lifecycle policy.

>> 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?
>

See my comment before. Also: We already put a bunch of background
services in place, an updated version of the location service is about
to land. Push notifications are well on their way, too. With that, and
given the numerous updates by individual teams being reported to the
mailing list, I wonder what else would help in terms of documentation?
I agree that it would be great to have complete SDK and API docs
available and any help is appreciated to reach that point. And feel
free to reach out to me on irc.

>> 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).
>

Sorry, but I think you are ignoring the arguments that multiple people
have presented in this mail thread. We have pointed out that we are
well aware that we are taking a somewhat conservative and strict
choice to ensure predictable battery life and performance. None of the
alternative approaches presented in this thread qualify for
predictable battery life and performance, they all focus on solving
the perceived issue of a lack of flexibility for application
developers.

Again: I think we should save the time we already invested on this
mail thread and instead focus time and energy to extend and enhance
the chosen path of a strict lifecycle policy for mobile devices in
version 1.

Thomas