Re: Speeding up browsing and lightening the traffic load
Am Di 8. April 2008 schrieb Mikko Rauhala: > 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. [...] > > 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 > browsing. > > 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... Andy Green is considering a VPN based concept that's close to this. jOERG ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Speeding up browsing and lightening the traffic load
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 timeout. > > 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.) > > 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 this image is the full-quality one", or "add javascript to pop up a menu 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 browsing. 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 <[EMAIL PROTECTED]> University of Helsinki ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Speeding up browsing and lightening the traffic load
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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Speeding up browsing and lightening the traffic load
Mikko Rauhala ha scritto: 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 I've found a video about links2 in OpenMoko [1]. It seems cool, but not exactly usable with fingers (neither with stylus, really!). [1] http://tinyurl.com/5uexmp -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Speeding up browsing and lightening the traffic load
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 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). 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. Oh yeah, the interproxy communication thing would need some work as well, currently being plain http. My intent is to personally use ssh -C for a transport service, so I'll get "for free" persistent protocol compression (on top of the ml/rdiff) and encryption for the over-the-air part. Someone more proficient in twisted would likely easily write a nice compact persistent custom protocol with internal async muxing and stuff. Annyway, thought I'd mention this even though, as said, my proxy is in a prototype stage, because, you know, this being an open phone, there's no need for one to limit oneself to proprietary solutions, even if there's not a free one available right this instant. -- Mikko Rauhala - [EMAIL PROTECTED] - http://www.iki.fi/mjr/> Transhumanist - WTA member - http://www.transhumanism.org/> Singularitarian - SIAI supporter - http://www.singinst.org/> ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
