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

Given the various issues and questions raised about this proposal, I 
don't support adding it to WebApps (at least not now).

I do support work in this area and agree a new CG is one possibility. It 
also seems like the work could be argued as in scope for the native Web 
apps CG which includes application packaging formats [1].

-AB

[1] http://www.w3.org/community/native-web-apps/wiki/Main_Page

On 2/14/12 1:26 PM, ext Marcos Caceres wrote:
> 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 Thursday, 16 February 2012 12:40:42 UTC