Re: Native delta updates

Thanks, Tobie,

Needless to say, we (Gmail/Apps/others at Google) are really interested in
this and welcome any help and participation.

The slides are here:


On Fri, Nov 9, 2012 at 2:14 AM, Tobie Langel <> wrote:

> Hi all,
> I saw Robert's slides on delta updates and read the workshop's minutes.
> I would like to add a couple of points as native delta updates are, with
> AppCache, one of the keys to allow building rich client-side apps on the
> mobile Web platform.
> A typical rich client-side application is easily composed of hundreds of
> different JS files nowadays. In order to fight latency issues, developers
> (rightfully) concatenate all of their JS files together to transport them
> to the client. Admittedly, with SPDY/HTTP2 this might no longer be
> necessary, but that still needs to be proven.
> While concatenating JS files is a net gain in terms of latency, it also
> implies that a single line change in a single JavaScript file causes a
> complete cache bust. This issues is orthogonal to whether or not AppCache
> is being used. With continuous deployment techniques increasingly getting
> traction (e.g. Twitter and Facebook push daily to their mobile website),
> this implies daily cache-busts, which artificially inflates bandwidth
> usage and increases load times.
> There are various techniques to fight this. Among the mobile web apps we
> surveyed[1][2] as part of our fixing-appache effort[3], pretty much all of
> them stored their JS in localStorage and did some form of delta updates on
> it (whether it was true diffs or per module updates). But there are
> performance associated costs with this (getting stuff from localStorage is
> not free[4]), security concerns[5] and a large engineering overhead which
> is paid for every app that wants to implement this. While WebCrypto APIs
> help mitigate the security threat, they still imply an overhead to the
> developer who needs to be aware of the threat and defend against it
> accordingly.
> For these reason, diff updates should be transparent to client code and
> probably belong at the http level. Some vendors have already expressed
> interest in this. It would be fantastic to see it through. Suggestions as
> to what the best platform for moving this forwards, and what stakeholders
> besides vendors should be sitting at the table are more than welcome.
> Best,
> --tobie
> ---
> [1]:
> [2]:
> [3]:
> [4]:
> visited/
> [5]:
> html

Robert Hundt

Received on Tuesday, 13 November 2012 14:32:32 UTC