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 <bruan...@gmail.com> 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
>> package.zip/index.html 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@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-weba...@w3.org certainly.
>
> David
>
> [1] http://www.w3.org/TR/widgets/
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
