This could especially increase the speed of browsing in threaded discussions (like in Slashdot or many other bloglike sites), but also bulletin boards, news-websites and collaboration platforms (like wikipedia).

The way it is now, every time you browse on a website created by request, the browser will have to download the whole page again, even when nothing or very little changed; just because it could have.

So here is my suggestion: When the webserver initially sends out a website, it puts a timestamp in there. So if they browser notices the same request is sent out a second time, it adds the diff-http identifier and the delivered timestamp to the request. The webserver holds a cache of recent versions and differences to the most recent. It sends out only a patch to the original html-file, in case the page with a timestamp older than the one sent is still in cache.

Possible extensions could be:

- The webserver sends out how the different request-fields relate to the feature. The ID-field, for example, defines the page. The session ID on the other hand doesn't influence the website much and can be seen as another timestamp. This feature has to be used with care on public computers.

- Extend the feature to all pages on a website, not just the one displaying the same content. This way, navigational elements don't have to be retransmitted. It's a balance between serverside CPU usage and needed bandwidth.

- If there is no such serverside implementation, it still makes for a good feature in the browser itself, if it can handle such diff files. The browser will just run diff itself while downloading. It tells the browser which parts of the document it has to realign and repaint, leading to faster rendering and less flickery display on half-loaded html pages on the same site.
-- fuqnbastard, Jun 24 2004

http already has timestamps; assuming things are set up correctly then a page doesn't have to be downloaded again if nothing has changed.

Transferring diffs/updates of web pages sounds like a new idea though (unless you count client-side scripts that talk to proprietary servers/extensions thereof to do the same).
-- benjamin, Jun 24 2004


As I understand it, when a page is unchanged from the previous visit, the server will send a response 304 and the browser will pull the page from cache (assuming it's in cache). This idea would require the server to maintain a full history of all changes to each page so that it could 'patch' any request. If a page has changed 400 times since it was written, and 400 different browsers requested the page, they may well each require 400 different patches. The benefit to the browser seems to be small compared to the additional requirements on the server.
-- angel, Jun 24 2004


( benjamin ) You're right, that's an aspect, you could implement this as javascript. However, back when I was creating websites, programming in JavaScript was a pain. How little it is applied to problems my idea is thought for, seems to indicate that it still is.
-- fuqnbastard, Jun 24 2004


( angel ) It's not meant to replace the browser cache. It's meant to speed up posting operations. Between when you started writing your comment and after you comfirmed it there usually aren't too many changes to a page.
-- fuqnbastard, Jun 24 2004


Ah, I think I see. Is it analogous to the way ASP or PHP builds a page on the server by referring to a database then transmits the result to the browser? Here, it's moved down a level, so your new layer is requesting the data fields (just the ones changed from the version held in cache) from the server and re-building the page on the browser?
-- angel, Jun 24 2004


I don't think the "diff" is worth it - it's asking a lot from server and client. Maybe ten years ago, when data speeds were slower.

It is difficult to track source changes through a rendering process. If the flickering is annoying, you're better off rendering into an off-screen bitmap and updating only those pixels that changed.
-- jutta, Jun 24 2004



random, halfbakery