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<[email protected]
(mailto:[email protected])> 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
