Re: Reboot: Strategic goals for GNOME
- From: Jim Gettys <jg freedesktop org>
- To: Philip Van Hoof <pvanhoof gnome org>
- Cc: foundation-list gnome org, andrew operationaldynamics com, rms gnu org
- Subject: Re: Reboot: Strategic goals for GNOME
- Date: Sat, 06 Mar 2010 08:15:55 -0500
Philip Van Hoof wrote:
On Fri, 2010-03-05 at 07:51 -0500, Jim Gettys wrote:
I'm doing a huge [CUT] here, I hope you don't mind?
People like Google work *hard* on latency and understand
every byte counts (among many other things: go look at the google talks
by their engineers on the topic).
In my opinion you solve latency more by making services capable of
pipelining, than by compressing data. And by making clients that make
use of the remote service's pipelining capabilities.
They do both routinely. Go listen to the technical talks.
But initial startup time is also considered a major latency issue.
The perceived latency will include the time to decompress the compressed
chunks (when using a compression algorithm instead of code obfuscating,
is negligible compared to average network latency. Especially on 3G,
UMTS and (all) other mobile network protocols.
In other words:
UI and client developers should learn to build state machines instead of
threads that work like (where [...] is ~ an IP frame):
"[ask], wait, [receive], process, [ask], wait, [receive], process"
Instead of that, do this:
"[ask ask ask] [receive receive], process, process, [receive], process"
Thank you very much for explaining HTTP/1.1 pipelining to the former
editor of the HTTP/1.1 standard... ;-)
An example of this is Dave Cridland's Polymer and Telomer.
technologies. Meaning that GNOME's desktop technologies has an advantage
Especially for mobile is this interesting (where from quite some time to
come, network latency will be the problem numero uno).
No, this is not the incentive driving toward obfuscation of code: the
apps get cached just like other web content; what you say about latency
is true in the general case, but not the case I'm pointing out.
I'm making the point that HTML 5 enables longer term and off line use of
cached apps, in a standardized way (a great improvement over google
gears or adobe air).
The issue encouraging obfuscation is *first time* use of applications,
or updates to applications. Web applications can and often are updated
much more often than conventional apps have been; it is a fundamental
advantage they have due to the improved distribution channel.
My point, fundamentally, is that we must ensure that free software
alternatives never work *worse* than proprietary. This should be be a
minimum standard we strive always to achieve.
] [Thread Prev