Re: Reboot: Strategic goals for GNOME

[Jim Gettys <jg freedesktop org>]

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,
> like they do with javascript as you point out), but I'll agree that this
> 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.
>
> This, however, isn't always simple with the newest "HTML5 + Javascript"
> technologies. Meaning that GNOME's desktop technologies has an advantage
> here.
>
> 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.
			Best Regards,
				- Jim