ubuntu-phone team mailing list archive

[Benjamin Zeller <benjamin.zeller@xxxxxxxxxxxxx>]

Am 02.10.2015 um 13:29 schrieb Michael Zanetti:
> 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.
I can only completely agree with you. Chasing a solution we can never
reach is pointless, even if it is the theoretically perfect solution.
We need to make a trade off between the complexity of a solution
and resources we have available.
> > 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.