Speeding up browsing and lightening the traffic load

[Sander van Grieken]

On Monday 07 April 2008 12:13:17 Mikko Rauhala wrote:
> ma, 2008-04-07 kello 11:24 +0200, Erland Lewin kirjoitti:
> > IMHO, the Opera Mini design (compressing and optimizing web pages
> > before sending them to the phone) is excellent, because it saves
> > traffic (=money) and speeds up loading.
> >
> > I'm not aware of any open source alternative with the same design.
>
> Over the last weekend, I've been working a bit on a prototype proxy
> doing streaming html/xml diffs (dubbed mldiffs) based on a shared cache,
> largely as described here: http://wiki.openmoko.org/wiki/Server:WebProxy

Hi

I wanted to  let you know I added the following to your wiki entry:

"improvement: it would be better NOT to modify the client, but instead have 
a 'reassembly proxy' on the client, so that all http clients/user agents 
benefit without hacks. The reassembly proxy could then inject a cookie to 
keep track of page versions."

Also, with pictures the proxy pair could detect on the second load it has 
already sent the 'crappified' image and send a diff with the 
next 'progression' of the image. That way the user can get the full quality 
image with 2 or 3 page refresh actions.

> Sadly, going by track record, I probably will not have the energy to
> productize the thing, but maybe it'll provide inspiration and/or a basis
> for someone to do so. I do intend to get at least the mldiffs going
> (currently just need to debug the interproxy communication, other stuff
> is done) and hopefully add rdiff support for non-ml content (during
> testing I found the mldiffs to be notably better for markup content so I
> started with that). Then I'll put the (python/twisted) source out there
> (if someone's really interested for it now, feel free to ask).

I think it's a great idea!

> Image crappification support would be good, but I don't know, it would
> really require inserting javascript or at least mucking with the (x)html
> to work nicely with a browser knowing nothing of this. (You know,
> something along the lines of click the image the first time, and you'll
> get a better version; second time does what it normally does.) I'm not
> sure if that's something I want to tackle with. OTOH, simple
> crappification controlled from a configuration key on the client might
> be doable with my concentration levels, we'll see.

No need for hacks with the two-proxy scenario

It might even be extended to a session manager that keeps your (XMPP, IRC, 
etc) sessions open even when switching from Wifi to GPRS or vice versa. This 
would make possible 'handovers' when losing Wifi coverage. The server and 
client proxies just reconnect over the other channel while the endpoints will 
not disconnect.

grtz,
Sander