On Mon, Aug 09, 2010 at 11:24:53AM +0100, Alan Cox wrote:
[ . . . ]
would agree that in the ideal world, it would be nice if you could
have applications that make the correct performance/battery
utilization tradeoff for devices running on 800 mWh batteries, 94,000
mWh batteries, and while running on the AC mains. But I don't believe
that it's likely to be true, and if you want to try to beat up on
application writers one at a time to be power optimized --- as far as
I'm concerned, that's an argument *for* suspend blockers, since I'm
not big believer in plans that begin, "First, you command the tides of
the sea to go back", King Canute style. :-)
Suspend blockers drive the system policy part way into the apps, that in
turn makes the apps very vulnerable to change in their environment because
you've specialised them. I am sure that in the Android world it's
considered fine, and that the marketing and business people even like
this binding together - but it doesn't generalise and will blow up in
people's faces in the future.
To consider your tide analogy - suspend blockers is like trying to
program the waves individually. Show me a suspend blocker aware open
office patch 8)
But wouldn't an office suite run as a power-oblivious application on an
Android device? After all, office applications do not need to run when
the screen is turned off, so these the applications do not need to use
suspend blockers. That said, I could easily imagine that significant
work would be required to make OpenOffice run on Android, not due to
suspend blockers, but rather due to Android's unusual user space.