http://googlediffable.blogspot.com/

Thanks for the feedback and sorry for the graph and the delay in fixing it!

I think this can be bundled with some SVN/git code to make it easier for people to implement. It can also help with predicting proper expiration window based on historical data for example.

We have come up with two wails to deal with the issue you raise. The first, easier way is to change the URL, and this is what we currently do. When the deltas become so large as to offset the benefit of patching, we simply start over by changing the script URL. The second way, which we haven’t actually gotten a chance to play with yet, is to set a valid expires time on the base scripts. If the expires time is, say, 2 weeks, then you would hypothetically only ever need to keep around 2 weeks worth of deltas.

Returning to Kroc’s point, the “expires never” on the specific versions will lead a commonly used site to always base on the first whole version downloaded.

Extending the example, when version 3 is pushed to the server, the client will find v1 in cache and request v1->v3. When version 10 comes out, until the cache entry for v1 is expunged, the client will again request relative to v1, that being v1->v10.

Of course, writable local storage will fix this.

Reminds me of Marimba’s Castanet way way back in the day.

(Spam blocker: “3 times tin =”? )

Thanks for the response.

The main problem with this approach occurs when there are dependencies between your client and server. If this is the case, then everyone must get the latest version of the client when the new version of the server is pushed. Otherwise, having two possible client versions in the wild would mean you would need to run both versions of the server, and direct between the two. If this issue is not a concern, then you could definitely take the approach you describe, and in fact this is the approach HTML5 AppCache uses.

I think you are absolutely right, and hopefully all of these ideas can be incorporated into the project. I am currently working on bootstraps for CSS and HTML content. I am also working on making the bootstrap code aware of other resources in the current page, allowing multiple resources in a page to be patched with a single diff request. Lastly, getting a working apache module is a top priority. I would love to be able to stick an apache server in front of the content server and have it do all the modifications automatically.

Thanks a lot for your interest! All contributions would be greatly appreciated. :)

Thanks again for presenting this interesting idea. I think it might be possible to manage this in the context of static-only CDN (I’m thinking Amazon Cloudfront or AppEngine’s built-in CDN) via offline pre-computation of diffs and careful management of page expiry.