Speeding up browsing and lightening the traffic load
mjrauhal at cc.helsinki.fi
Tue Apr 8 13:05:48 CEST 2008
On ti, 2008-04-08 at 11:30 +0200, Sander van Grieken wrote:
> > 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
> "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."
Yeah that's actually pretty much what I've done so far. Using a custom
header, to be exact.
> 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.
Mm, that mechanic could work, if hopefully one could distinguish between
reloads and arriving on the page again at a later time. Besides a
> > Image crappification support would be good, but I don't know, it would
> > 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.)
> No need for hacks with the two-proxy scenario
I was mostly thinking along the lines of "transform img reference to a
crappified one, along with a surrounding link to a page version where
when image is clicked to load the full quality image or just do whatever
the original page wants to do when the image is clicked".
Exactly this sort of hacks are necessary for this sort of fine-grained
tuning without modifying the browser.
> 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.
Now this is an excellent idea, but I'm not so sure if it should be an
extension of this. First, a mobile diffing proxy is useful in many
places where one might not need those other things, and second, it's
less important to keep a single session going all the time with web
Also, such a session manager would be rather simple on its own, which is
always a nice thing for maintainability. The web proxy could perhaps
just be routed through it, though; it would make things smoother for it
too in some situations.
Should really also check if someone's already done that sort of thing,
one would think someone might've...
Mikko Rauhala <mjrauhal at cc.helsinki.fi>
University of Helsinki
More information about the community