Generic Bundling

Andrea Giammarchi andrea.giammarchi at
Fri Oct 11 12:39:18 PDT 2013

I think not only me used the term bundle thinking about packaging, I cannot
think about anything else that would need a .zip file ;-)

Agreed that this might be the wrong place but also it's surprising that
there was a W3C recommendation and Mozilla, the most standards promoter I
know, ignored it.

In my dreams there is a packaging solution simple to implement, polyfill,
fallback, and interoperate between platforms so while the discussion should
continue somewhere else, would you mind concluding this thread explaining
why FirefoxOS went for a non standard approach? Is the FirefoxOS approach
proposed as standard alternative? I prefer the manifest too, for what is
worth it, but if not standard, I would not consider it.

Best Regards

On Fri, Oct 11, 2013 at 12:02 PM, David Bruant <bruant.d at> wrote:

> Le 11/10/2013 19:01, Andrea Giammarchi a écrit :
>  As I've said, you keep confining the problem and the solution over HTTP
>> and servers while I see this approach, maybe slightly revisited, a good
>> **generic bundling** solution even without a server and easily adoptable
>> now plus this will not mean HTTP 2 won't be handy to help with this case
>> too.
> We seem to differ in what we think of the solution, because we don't seem
> to address the same problem. For me, "bundling" is a way to prevent
> round-trips (whether it is to the network or to disk). You seem to want
> what is (by me at least) usually referred to as "packaging".
> Dave Herman or others will disconfirm if I'm wrong, but I think "generic"
> here was in opposition with previous proposals were JS/module-only bundling
> was proposed. In that context, "generic bundling" just means "bundle
> heterogeneous resources" which is different from packaging.
> On saving network round-trips, server push seems to be the way forward. On
> saving disk round-trips, various app manifest formats (at least the two I
> know from FirefoxOS and Tizen) can be easily extended to declare which
> resource should be put in-memory as soon as the app starts.
> Now, let's talk about packaging.
>  The proposal could be revisited to tell browsers to look for
>> automagically once opened so we'll have a bundle
>> that can work over HTTP and over Bluetooth exchange too.
> Both FirefoxOS and Tizen (if someone have infos on other OSes with "web
> apps"...) took a different approach, that is having a stable manifest file
> location in the package and this manifest file points to the main HTML file
> ("launch_path" property on FirefoxOS, content at src for Tizen)
> Interestingly, this has all been working well without having to change
> HTML even a little; without having to add a new HTML attribute or new @src
> value semantics, specifically!
>  So, my counter question would be: do we have a standard generic bundle
>> option that works same way every other programming language has ? (war
>> files, python distributable with self extracting archive and execution,
>> .NET apps, etc etc etc)
> We do not (not as far as I know at least). There is the widget spec [1]
> which is as mature as being a W3C Recommandation. That's what Tizen is
> based on, but FirefoxOS chose a different path (hopefully, it's not only
> because it's XML based :-p)
>  If such thing exists plus HTTP2 will solve all other problems then I
>> agree it's not a good idea to implement this now.
>> If such thing does not exist I would like to keep thinking the
>> combination JS + HTML + CSS can offer a lot even without a webserver behind
>> or any protocol ... there is a database that does not need a connection and
>> all tools needed to offer great applications.
> Yes. I think we should continue this discussion in a more appropriate
> place though; public-webapps at certainly.
> David
> [1]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list