ubuntu-phone team mailing list archive

[Michael Zanetti <michael.zanetti@xxxxxxxxxxxxx>]

On 02.10.2015 12:55, Olivier Tilloy wrote:
> 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

To add one, and this applies to many of the suggested "solutions". Even
if it would work, it really doesn't sound like anything we could achieve
with the given resources. We need to be realistic on what we can do and
what we can't. There's no point in having the theoretically correct
solution on paper but nowhere near the product within many years from now.

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

Attachment: signature.asc
Description: OpenPGP digital signature