Re: CfC: Proposal to add web packaging / asset compression

Hi guys,

I'm not particularly set on one direction to solve this problem. I just want to get it solved, and if SPDY, along with a much improved programmatically controllable appCache is the preferred solution, let's go for it.

I, along with probably plenty of other web developers, am still inexperienced with SPDY, and thus, maybe we should take this conversation into a different direction, trying to come up with a backward-compatible SPDY demo that solves every issue of asset delivering and caching. Here's a rough list of things it needs to do:


  *   transfer an initial set of assets to the client to display the page (game)
  *   later on, pull subsequent packages of assets when needed
  *   Cache sets of assets locally
  *   Request delta updates for cached asset packages

If these are all manageable with SPDY, I'm in. Last question – where is the standards work of SPDY happening? All I could find was this page http://www.chromium.org/spdy, that points to three expired documents submitted to IETF.

Thanks,
Paul

Von: Yehuda Katz <wycats@gmail.com<mailto:wycats@gmail.com>>
Datum: Tue, 14 Feb 2012 11:54:47 -0800
An: "Tab Atkins Jr." <jackalmage@gmail.com<mailto:jackalmage@gmail.com>>
Cc: Paul Bakaus <pbakaus@zynga.com<mailto:pbakaus@zynga.com>>, "public-webapps@w3.org<mailto:public-webapps@w3.org>" <public-webapps@w3.org<mailto:public-webapps@w3.org>>
Betreff: Re: CfC: Proposal to add web packaging / asset compression

I would agree with this. My initial thought when reading the proposal was SPDY as well.

That said, there is ongoing discussion about improving the app-cache that is also relevant[1]. I am also planning on opening a discussion about programmatic control of a cache (probably not piggy-backed onto app-cache, which has important atomicity guarantees and no programmatic control, but possibly piggy-backed off of the File API). Between SPDY, improving app cache semantics, and a clean way to programmatically store remote assets that can be loaded via <script>, <link> and <img> tags, I think we have a solution that does not require creating a new packaging format.

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=14702

Yehuda Katz
(ph) 718.877.1325


On Tue, Feb 14, 2012 at 10:26 AM, Tab Atkins Jr. <jackalmage@gmail.com<mailto:jackalmage@gmail.com>> wrote:
On Tue, Feb 14, 2012 at 1:24 AM, Paul Bakaus <pbakaus@zynga.com<mailto:pbakaus@zynga.com>> wrote:
> Hi everybody,
>
> This is a proposal to add a packaging format transparent to browsers to the
> charter. At Zynga, we have identified this as one of our most pressuring
> issues. Developers want to be able to send a collection of assets to the
> browser through a single request, instead of hundreds.
>
> Today, we misuse image and audio sprites, slicing them again as base64 only
> to put them into weird caches. These are workarounds, and ugly ones, as
> well. None of the workarounds is satisfying, either in terms of robustness,
> performance or simply, a sane API. Coincidentally, this is also one of the
> most pressuring issues of WebGL. Since you are dealing with a lot of assets
> with WebGL games, proper solutions must be found.

I was once a believer in an approach like this, and supported previous
attempts at it like Mozilla's use of a zip + virtual paths.

Now, though, SPDY seems to be moving along nicely enough that we don't
really need to worry about this.  It's already supported in Chrome and
Firefox, and it lets you pull multiple assets in a single connection,
push assets that haven't yet been requested, and prioritize asset
retrieval.  I don't feel there's any real need to worry about asset
packaging formats anymore.

~TJ