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

I have the itching feeling that a Community Group might be the right place to do the exploratory work. Once there is a solid proposal for standardization (and hopefully a prototype), it should be brought back here.

To start a community group:  
http://www.w3.org/community/

And since we are top-posting :)… I can see quite a few issues with the proposal below (e.g., seems to rely on file extensions, instead of MIME type, etc… seems to break some REST principles etc…. lack of error handling, "file/not/found?") plus some nice to haves (instead of callbacks, progress events might be nicer, so you get notified as each file in the package becomes ready for use… also, a streamable format… I think the Moz guys already did a whole bunch of research into this last year and proposed it to the WHATWG… the W3C also did a whole bunch of work on this about 12 years ago, but I'm having a hard time finding the link to that work).

Again, sorry for the lack of references; hopefully the right people will jump in and provide those.  
   
--  
Marcos Caceres


On Tuesday, February 14, 2012 at 6:12 PM, Dimitri Glazkov wrote:

> Though I don't know what shape this will take, I think this is
> definitely worth vigorous research and discussion.
>  
> Without trying to derail this effort, I am somewhat interested in how
> this thinking can be applied to Web Components, since components may
> want to be coupled with various assets.
>  
> :DG<
>  
> 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.
> >  
> > A ticket at Mozilla, describing the issue further, has been opened by us
> > here: https://bugzilla.mozilla.org/show_bug.cgi?id=681967
> >  
> > Here's an actual code draft I attached to the ticket:
> >  
> > window.loadPackage('package.webpf', function() {
> > var img = new Image();
> > img.src = "package.webpf/myImage.png";
> > })
> >  
> >  
> > Or alternatively, with a local storage system (I prefer option one):
> >  
> > window.loadPackage('package.webpf', function(files) {
> > files[0].saveTo('myImage.png');
> > var img = new Image();
> > img.src = "local://<absolute path of url of site>/myImage.png";
> > })
> >  
> >  
> > No big deal if the whole API looks entirely different when it's done. The
> > format needs to be able to handle delta updates well, and must be cacheable.
> > It needs to be transparent to the browser, and assets of uncompressed web
> > packages need to be able to be included from CSS. I am aware this is a more
> > inconvenient addition to work on, but there is immediate need.
> >  
> > This is also a call for implementors, testers and editors. I am
> > unfortunately not experienced enough to handle any of those jobs.
> >  
> > Thanks, I'm looking forward to feedback!
> >  
> > Paul Bakaus
> > W3C Rep and Studio CTO, Zynga
>

Received on Tuesday, 14 February 2012 18:27:03 UTC