ubuntu-phone team mailing list archive

[Olivier Tilloy <olivier.tilloy@xxxxxxxxxxxxx>]

On Fri, Oct 2, 2015 at 12:10 PM, Matthew Paul Thomas <mpt@xxxxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Alan Bell wrote on 01/10/15 12:25:
>>
>> I quite agree, even if it is a user preference it would be fine,
>
> Making background processing a user preference would be the worst
> possible approach. It would mean sometimes having to choose between
> battery life and an app that works. It would mean users experiencing
> different things, from the same app on different devices, and not
> understanding why, never realizing that it was because they twiddled
> the setting a year ago to see what it did and then forgot about it. It
> would mean app developers often not experiencing their own apps the
> same way that most of their users were. It would mean silly nag
> screens in some apps prompting you to change your multitasking
> setting. And for a combination of those reasons, it would require
> people to learn what "background processing" is, and make a decision
> about it, when most of them have far, far better things to do with
> their lives.
>
>> I would choose to have multitasking when the screen is on. I find
>> it rather frustrating on slow connections to be unable to
>> background the web browser to let it load something while I check
>> on other things.
>>
>> ...
>
> Notice how Safari on an iPhone doesn't have the same problem, despite
> not multitasking. Half-load a page, switch to another app, switch back
> a while later, and the whole page will usually be loaded. (Except
> maybe bits that were to be loaded by scripts that were frozen.)
>
> So, multitasking is not the only solution to that problem.
>
> A better solution, perhaps, would be to expand the Download Manager
> service.
> <https://developer.ubuntu.com/api/apps/qml/sdk-15.04/Ubuntu.DownloadManager.index/>
>
> First, make it accept more than just an URL. You can encode HTTP
> authentication into an URL, but you can't provide cookies, client
> certificates, a POST form payload, or even an HTTP Referer.
>
> Second, instead of making it an opt-in API for apps to use for "a long
> running connection", just make it automatic for every transfer.
> There's little point in halting a transfer because an app is going
> into the background; the app will usually just restart it again later,
> using more battery (and more data) in the long run.
>
> If those two things were done, the Web browser could use it for almost
> everything. So as long as the HTML of a page had been loaded, with the
> other resources requested, the rest of the page would load in the
> background.

While that might sound like a solution to the problem on the paper, it
won’t fly, for several reasons:

 - afaik this is not part of the design goals of udm, so it might
require quite some refactoring (or even a complete rewrite) to catter
for this new use case

 - oxide (and chromium under its hood) has a highly optimized engine
to perform HTTP requests, tailored especially for the browser
use-case, that can handle a number of concurrent requests. It would be
naive to think we can replicate that in udm without a significant
effort and finite resources, if at all possible

 - that engine is not meant to be easily replaced in chromium, trying
to do so would result in a significant amount of work (again, if at
all possible), and an increased maintenance cost

That doesn’t mean we shouldn’t try and think of clever solutions to
this problem. Ensuring that a page is fully loaded before the
corresponding process is suspended, to avoid CPU and data consumption
later on when the browser regains focus, is desirable.