ubuntu-phone team mailing list archive

["Alejandro J. Cura" <alejandro.cura@xxxxxxxxxxxxx>]

On Thu, Mar 6, 2014 at 2:14 PM, Barry Warsaw <barry@xxxxxxxxxx> wrote:
> On Mar 06, 2014, at 02:13 PM, Alejandro J. Cura wrote:
>
>>So, while the updates are downloading, how is s-i kept alive if the
>>user switches to other apps? Is it somehow escaping the app lifecycle?
>
> Yes, because s-i isn't an app.  It's a system bus service itself which is
> invoked by system settings via D-Bus activation.  (It actually starts a u-d-m
> instance on the system bus too.)
>
>>Also, is there a reason for that? For the scope there is no reason, so
>>I think it's better for it to die and free the ram.
>
> Yes, because s-i is the mediator between the ui (i.e. system-settings) and
> udm.  It actually makes several group download calls to udm in order to
> perform and validate a system update.
>
> But you say the scope has no reason to stay alive.  Wouldn't "responding to
> the 'finish' signal" be a good reason?

Hi Barry, thanks for this discussion, it has helped clear my head on
how this should work.

No, I don't think "responding to the 'finish' signal" is good enough
of a reason to keep the scope alive. I still think that udm doing
*something* when the download is completed is the right way to go.

Scopes are started by the scope-runner when needed, and they might be
killed too if needed or if they are idle. This makes sense, since we
don't want to keep ram allocated to them if they are waiting, and
since they are usually cheap to restart. I hear that there's work to
make the dash work like any other app, so it might be also subjected
to the app lifecycle, and it would make sense for the scope-runner to
be stopped in that case too.

In any case, 3rd party apps using the download manager service will be
subject to the app lifecycle, and they very likely won't be around to
listen to that signal.

Furthermore, the download-manager knows how to retry downloads even
after a reboot, and again, apps (or scopes) won't be even started.

cheers,
-- 
alecu