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:
  http://www.w3.org/2012/11/performance-workshop/agenda.html

Best
   Robert

On Fri, Nov 9, 2012 at 2:14 AM, Tobie Langel <tobie@fb.com> 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]: https://etherpad.mozilla.org/appcache-london
> [2]: https://etherpad.mozilla.org/appcache
> [3]: http://www.w3.org/community/fixing-appcache/
> [4]:
> http://www.nczonline.net/blog/2012/04/25/the-performance-of-localstorage-re
> visited/
> [5]:
> http://lists.w3.org/Archives/Public/public-webcrypto-comments/2012Aug/0057.
> html
>
>


-- 
Robert Hundt