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 [email protected] http://lists.openmoko.org/mailman/listinfo/community
